Model data adaptation processing method and device for graphic rendering engine and storage medium

Abstract

The invention relates to the technical field of computer graphics, and provides a model data adaptation processing method for a graphics rendering engine, which comprises the following steps of: importing and analyzing model files from different geometric modeling engines, and extracting original geometric data, original topological data and auxiliary information in the model files; converting the original geometric data into a unified standard geometric data structure for representation and storage; converting the original topological data into a standard topological data structure based on a boundary representation method for representation and storage; creating, analyzing or setting spatial position and direction information of the model entity and the virtual camera in a world coordinate system; analyzing material attributes, surface textures and animation information in the affiliated information of the model file, and packaging the materials, the surface textures and the animation information into corresponding standard data structures; and combining the standardized geometric data, topological data, coordinate system information and affiliated information into a complete standardized model data packet which can be directly used by a graphic rendering engine.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer graphics, in particular to a model data adaptation processing method, device and storage medium for a graphics rendering engine. BACKGROUND

[0002] With the rapid development of computer graphics technology, three-dimensional models have been widely used in digital twinning, virtual reality, video games, industrial design and many other fields. These three-dimensional models are usually created by professional geometric modeling software (such as CAD, BIM software), and the core is a geometric modeling engine, which is responsible for all calculations and operations related to geometric shapes and finally outputs model data as a file in a specific format.

[0003] In order to facilitate data exchange and sharing between different software and platforms, the industry has developed a variety of standard file formats, such as STEP, IGES, OBJ, STL, etc. These formats have different focuses in different application scenarios: for example, the STL format uses a triangular mesh to simplify the representation of geometric surfaces, which is convenient for slicing processing in 3D printing, but it does not store color, texture and other auxiliary information, which will result in loss of model details; the STEP format is committed to comprehensively and accurately representing geometric entities, and can store rich information such as geometric shapes, topological structures, material properties, etc., but its file structure is complex, the data volume is large, and the cost of analysis and processing is high.

[0004] In the graphics rendering application scenario, the rendering engine needs to balance between rendering quality and rendering efficiency, and needs to directly use optimized model data. The existing general standard formats show their limitations when facing this specific demand: first, in order to meet the universality, these standard formats usually discard part of the characteristic information in the source file that is crucial to rendering, such as animation keyframes, high dynamic range material properties, complex texture mapping parameters, etc.; second, the specifications of these formats are relatively fixed and cannot be flexibly adjusted and optimized according to the real-time performance requirements of the graphics rendering engine or different multi-geometry engine data sources, making it difficult to preserve necessary details while ensuring efficient rendering performance. SUMMARY

[0005] The present application provides a model data adaptation processing method, device and storage medium for a graphics rendering engine, which provides a complete, efficient and directly usable standardized data package for the graphics rendering engine by uniformly converting multi-source heterogeneous model data.

[0006] In one aspect, the present application provides a model data adaptation processing method for a graphics rendering engine, the method comprising:

[0007] Import and parse model files from different geometry modeling engines, extract original geometry data, original topology data and auxiliary information therein;

[0008] Convert the original geometry data into a unified standard geometry data structure for representation and storage;

[0009] Convert the original topology data into a standard topology data structure based on the boundary representation method for representation and storage;

[0010] Create, parse or set the spatial position and direction information of model entities and virtual cameras in the world coordinate system;

[0011] Parse the material properties, surface textures and animation information in the auxiliary information, and encapsulate them into the corresponding standard data structure;

[0012] Combine the standardized geometry data, topology data, coordinate system information and auxiliary information into a complete and directly usable standardized model data package for the graphics rendering engine.

[0013] In another aspect, the application provides a model data adaptation processing device for a graphics rendering engine, the device comprising:

[0014] An extraction module for importing and parsing model files from different geometry modeling engines, extracting original geometry data, original topology data and auxiliary information therein;

[0015] A first conversion module for converting the original geometry data into a unified standard geometry data structure for representation and storage;

[0016] A second conversion module for converting the original topology data into a standard topology data structure based on the boundary representation method for representation and storage;

[0017] A coordinate processing module for creating, parsing or setting the spatial position and direction information of model entities and virtual cameras in the world coordinate system;

[0018] An auxiliary information processing module for parsing the material properties, surface textures and animation information in the auxiliary information, and encapsulating them into the corresponding standard data structure;

[0019] A combination module for combining the standardized geometry data, topology data, coordinate system information and auxiliary information into a complete and directly usable standardized model data package for the graphics rendering engine.

[0020] Thirdly, this application provides an electronic device, the device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the technical solution of the model data adaptation processing method for a graphics rendering engine as described above.

[0021] Fourthly, this application provides a storage medium storing a computer program, which, when executed by a processor, implements the steps of the technical solution described above for the model data adaptation processing method for a graphics rendering engine.

[0022] As can be seen from the technical solutions provided in this application, on the one hand, by converting the original geometric and topological data extracted from the model file into a unified standard data structure, the structural differences between different data sources are effectively eliminated, providing a stable and consistent data interface for the upper-level graphics rendering engine. On the other hand, by parsing and encapsulating the material properties, surface textures, and animation information in the model file's auxiliary information, the technical bias of losing such auxiliary information during the conversion process of existing general standard formats is overcome, ensuring that various information, including physical materials and complex animations, is completely preserved and transmitted to the rendering engine. On the other hand, by creating, parsing, or setting the spatial position and orientation information of the model entity and virtual camera in the world coordinate system, the positioning and viewpoint configuration of the model in the scene are more accurate and flexible, reserving interfaces for future integration of more types of geometric engines or rendering attributes, and having good scalability. On the third hand, by combining the standardized geometry, topology, coordinate system, and auxiliary information into a complete standardized model data package, the rendering engine can directly load and use the data without performing cumbersome format parsing and secondary data processing, thereby reducing preprocessing overhead before rendering and improving the efficiency of the overall rendering pipeline. In summary, the technical solution of this application provides a complete, efficient and directly usable standardized data package for graphics rendering engines by uniformly converting multi-source heterogeneous model data. Attached Figure Description

[0023] 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, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart of a model data adaptation processing method for a graphics rendering engine provided in an embodiment of this application;

[0025] Figure 2This is a schematic diagram of the structure of the model data adaptation and processing device for a graphics rendering engine provided in the embodiments of this application;

[0026] Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0027] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] In this specification, adjectives such as "first" and "second" are used only to distinguish one element or action from another, without necessarily requiring or implying any actual such relationship or order. Where circumstances permit, reference to an element, component, or step (etc.) should not be construed as limited to only one element, component, or step, but may include one or more of the elements, components, or steps, etc.

[0029] For ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn to actual scale.

[0030] To facilitate data exchange and sharing between different software and platforms, the industry has established several common standard file formats, such as STEP, IGES, OBJ, and STL. These formats have different focuses in different application scenarios: for example, the STL format uses a simplified triangular mesh to represent geometric surfaces, facilitating slicing in 3D printing, but it does not store additional information such as color and texture, leading to a loss of model details; the STEP format, on the other hand, aims to comprehensively and accurately represent geometric entities, storing rich information such as geometric shape, topology, and material properties, but its file structure is complex, data volume is large, and parsing and processing costs are high. In graphics rendering applications, rendering engines need to strike a balance between rendering quality and rendering efficiency, and require direct use of optimized model data. Existing general-purpose standard formats reveal their limitations when faced with this specific requirement: First, in order to meet universality, these standard formats usually discard some of the features in the source file that are crucial to rendering when outputting, such as animation keyframes, high dynamic range material properties, and complex texture mapping parameters; Second, the specifications of these formats are relatively fixed, and they cannot be flexibly adjusted and optimized according to the real-time performance requirements of graphics rendering engines or different multi-geometry engine data sources, making it difficult to ensure efficient rendering performance while retaining necessary details.

[0031] To address the problems of the prior art, this application provides a model data adaptation processing method for graphics rendering engines, the flowchart of which is attached. Figure 1 As shown, the main steps include S101 to S106, which are detailed below:

[0032] Step S101: Import and parse model files from different geometric modeling engines, and extract the original geometric data, original topological data and ancillary information.

[0033] Writing a dedicated parser for each specific geometric modeling engine file format, directly outputting to the graphics engine, would lead to enormous redundant development and maintenance costs. This is because each new file format or engine requires the redevelopment of an entire parsing and output logic, with parsers unable to share any processing logic, creating data silos. This approach is not only unscalable but also difficult to maintain. To provide a unified data access layer, this application can import and parse model files from different geometric modeling engines, extracting raw geometric data, raw topological data, and ancillary information. In this way, the complexity of different sources can be encapsulated within this step, providing a clean and unified input starting point for subsequent standardized processing, thereby achieving isolation between front-end data diversity and back-end data consistency.

[0034] It should be noted that the model files imported and parsed by the geometric modeling engines in the above embodiments are proprietary or standard format files used for persistently storing 3D model data, output by professional computer-aided design (CAD), building information modeling (BIM), or digital content creation (DCC) geometric modeling software (e.g., SolidWorks, AutoCAD, Revit, Blender, 3ds Max, etc.) after calculations and operations are performed by their kernel, i.e., the geometric modeling engine. The model file of the geometric modeling engine contains the data required to fully describe a 3D model, namely geometric data, topological data, and ancillary information, etc. For example, a .sldprt (SolidWorks), .dwg (AutoCAD), or max (3ds Max) file is a typical "geometric modeling engine model file." Even standard formats, such as .STEP or .IGES, fall into this category when they are exported by these engines because they carry data originating from a specific engine.

[0035] Specifically, as an embodiment of this application, the extraction of original geometric data, original topological data, and ancillary information from the model file can be achieved through the following steps S1011 to S1015:

[0036] Step S1011: Based on the format identifier of the model file, call the corresponding file format parser to read the binary or text stream of the file, decode the encoded data in the file into structured data objects in memory, and initially decouple the data streams for different purposes to different data processing channels;

[0037] Step S1012: Traverse the structured data objects in memory, identify and extract the mathematical definition data used to describe the shape of the model as the original geometric data. For parametric geometry in the original geometric data, extract its type identifier and parameter value. For free-form surfaces and curves, extract its control points, node vectors and order information, etc.

[0038] Step S1013: Parallel to or following step S10122, traverse the structured data objects in memory, identify and extract the connection and reference relationships between geometric elements as the original topological data, including extracting hierarchical relationship information such as how vertices are connected to form edges, how edges enclose to form faces, and how faces are closed to form solids, etc.

[0039] Step S1014: Traverse the structured data objects in memory, identify and extract material definitions, texture map reference paths, animation keyframes and layer attribute data as supplementary information; at the same time, parse and record the association between these supplementary information and the specific geometric or topological elements extracted in steps S1012 and S1013.

[0040] Step S1015: The original geometric data, original topological data and auxiliary information extracted and associated in steps S1012 to S1014 are encapsulated into internal intermediate data objects and output to the corresponding modules for subsequent conversion into standardized data.

[0041] Step S102: Convert the original geometric data into a unified standard geometric data structure for representation and storage.

[0042] As mentioned earlier, different geometric modeling engines use different mathematical expressions (e.g., different parametric curves and surface representations). Directly processing data from these engines with their varying mathematical expressions leads to complex and inefficient rendering computations. Theoretically, all graphics rendering engines could be required to support all types of geometric representation formats. However, this approach would significantly increase the burden on graphics rendering engines in practical applications, making them bloated and inefficient. In other words, the rendering engine would need to write different shaders, computational logic, and optimizers for each geometric format, resulting in a complex rendering pipeline, poor performance, and instability. Therefore, to achieve a unified geometric representation and provide a consistent and standardized geometric data interface for downstream graphics rendering engines, this application's solution is to convert the raw geometric data into a unified standard geometric data structure for representation and storage.

[0043] As an embodiment of this application, the conversion of the original geometric data into a unified standard geometric data structure for representation can be achieved through steps S1021 to S1023, as detailed below:

[0044] Step S1021: Determine whether the curve or surface in the original geometric data is a simple geometric entity that can be defined by a single mathematical expression.

[0045] As mentioned earlier, the original geometric data may contain parametric geometry, freeform surfaces, freeform curves, and more complex geometry. Accurately determining whether the curves or surfaces in the original geometric data are simple geometric entities that can be defined by a single mathematical expression can provide a basis for which model to use for subsequent processing. Specifically, determining whether a curve or surface in the original geometric data is a simple geometric entity that can be defined by a single mathematical expression can be achieved through the following steps S1 to S4, as explained below: Step S1: Traverse the mathematical representation structure of the original geometric data and extract its geometric type identifier, number of parameters, parameter value range, and mathematical expression complexity index, etc.; Step S2: Compare the geometric features extracted in Step S1 with a predefined simple geometric pattern library, which stores mathematical definition templates for various simple geometric entities (e.g., circles, ellipses, lines, planes, spheres, and cylinders, etc.), including their parameterized forms and expression features; Step S3: Based on the comparison result of Step S2, calculate the mathematical similarity between the current geometric entity and each simple geometric template. If the similarity exceeds a preset threshold, it is determined to be a simple geometric entity that can be defined by a single mathematical expression; otherwise, it is determined to be a complex geometric entity; Step S4: Output the determination result of Step S3 to the control logic of the geometric data standardization process to trigger the corresponding representation processing channel.

[0046] Step S1022: If yes, then call the predefined basic geometric model data structure to simplify its representation; otherwise, use the Non-Uniform Rational B-Splines (NURBS) model to accurately represent it.

[0047] Specifically, if the curves or surfaces in the original geometric data are simple geometric entities that can be defined by a single mathematical expression, then calling a predefined basic geometric model data structure for simplified representation and storage can be as follows: for circles or ellipses, store their center, the direction of the principal axis of the local coordinate system, and the radius or major and minor axis information; for straight lines, store their starting point, direction vector, and length information; for quadric surfaces, store their center point, parametric equation identifier, and corresponding parameter values.

[0048] Conversely, if the curves or surfaces in the original geometric data are complex geometric entities that cannot be defined by a single mathematical expression, then using the NURBS model to accurately represent and store the complex geometric entities can be done by: using a double-precision floating-point array of length 4 to store weighted control points; using one-dimensional or two-dimensional double-precision floating-point arrays to store the node parameters of the spatial curves or spatial surfaces respectively; and using integer data to store the order information of the NURBS model.

[0049] Step S1023: Provide a method for mutual conversion between the basic geometric model and the NURBS model.

[0050] Although different models have been invoked based on whether the original geometric data contains simple or complex geometric objects, this application can provide a method for mutual conversion between basic geometric models and NURBS models based on the aforementioned scheme, taking into account the following facts:

[0051] 1) In graphics rendering scenarios, the requirements for model accuracy and performance are dynamic. For example, when a model object is far away from the camera, in order to improve rendering efficiency, it may be necessary to convert the high-precision NURBS model representation into a simplified basic geometric representation. When the object is close to the camera, in order to preserve details, it may be necessary to convert the basic geometry back to the NURBS model representation. The mutual conversion method between models provides this dynamic adaptation capability, allowing the system to switch the representation form according to real-time rendering requirements (such as viewport size, performance indicators), thereby optimizing resource usage and rendering efficiency.

[0052] 2) In the model editing or data processing process, users may need to switch between different representations to perform specific operations (e.g., precise modification based on NURBS or quick preview based on basic geometry). The mutual conversion method between models ensures the mathematical consistency and information integrity of the data during the conversion process, avoids data loss or distortion, and thus enhances the practicality and flexibility of the solution.

[0053] 3) Different downstream graphics engines may have different preferences for data representation (e.g., some engines are optimized for parametric geometry, while others are good at NURBS). Therefore, the mutual conversion method between models enables standardized data packages to adapt to the needs of multiple engines, improving the versatility and scalability of the solution.

[0054] As another embodiment of this application, the original geometric data can be converted into a unified standard geometric data structure for representation through steps S'1021 to S'1024, as detailed below:

[0055] Step S'1021: Construct a hybrid geometry representation engine and use it to traverse and identify features from the original geometric data in the model file.

[0056] Step S'1022: Based on the recognition results of traversing the original geometric data and feature recognition, simple geometric entities defined by a single mathematical expression are diverted to the basic geometric representation channel, and a predefined parameterized model is used to perform high-performance representation of the simple geometric entities defined by a single mathematical expression.

[0057] Specifically, using a predefined parametric model to perform high-performance representation of simple geometric entities defined by a single mathematical expression can be achieved by: mapping the mathematical definition parameters of the identified simple geometric entity to a predefined set of normalized parameters for the basic geometric representation channel, for example, mapping an ellipse to the parameter set {center point coordinates, major axis vector, minor axis length, normal vector}; instantiating a lightweight data structure object based on the mapped normalized parameter set, which contains a parameter storage area and a pointer to its specific rendering processing function; registering the generated data structure object in the rendering resource manager and outputting its unique identifier for association with subsequent topology data and associated information.

[0058] Step S'1023: Divert the complex geometric entity to the NURBS representation channel and use the NURBS model to represent the complex geometric entity with high precision.

[0059] In the above embodiments, the routing of simple geometric entities to the basic geometric representation channel and complex geometric entities to the NURBS representation channel is performed dynamically based on the context of the real-time rendering scene. Specifically, this includes: receiving real-time performance metric feedback from the graphics rendering engine; dynamically adjusting the routing threshold based on the performance metrics and the estimated pixel ratio of the current model entity in the camera viewport; and redistributing the geometric entities between the basic geometric representation channel and the NURBS representation channel according to the adjusted routing threshold, so as to achieve dynamic optimization of the rendering load. The specific scheme for dynamically adjusting the splitting threshold based on performance metrics and the estimated pixel percentage of the current model entity in the camera viewport can be as follows: Obtain the real-time performance metrics of the current frame from the graphics rendering engine, and calculate the estimated pixel percentage of the model entity in the final rendered image based on the bounding box size of the model entity and its relative position to the virtual camera; input the real-time performance metrics and estimated pixel percentage of the current frame into a predefined strategy function, which outputs a dynamic splitting threshold. The strategy function is configured such that: under high performance pressure or low pixel percentage, the output tends to classify geometric entities as "simple" to improve performance; under sufficient performance or high pixel percentage, the output tends to classify geometric entities as "complex" to improve accuracy; update the calculated dynamic splitting threshold into the judgment logic of the hybrid geometry representation engine for subsequent splitting decisions of geometric entities.

[0060] As an embodiment of this application, using a NURBS model to represent complex geometric entities with high precision can be achieved by: performing renderability optimization analysis on the converted NURBS representation, identifying and marking surfaces with distorted parameterization or degradation parameters; and calling a numerical optimization algorithm to iteratively adjust the node vectors and control point weights of the marked surfaces to generate a numerically stable optimized NURBS representation suitable for texture mapping and surface subdivision. The specific scheme for using a numerical optimization algorithm to iteratively adjust the node vectors and control point weights of the marked surface to generate a numerically stable optimized NURBS representation suitable for texture mapping and surface subdivision can be as follows: Define a target energy function for the marked surface, which includes at least a term measuring the uniformity of parameterization and a term measuring the rationality of the control point weight distribution; use a gradient-based numerical optimization algorithm to iteratively minimize the target energy function; in each iteration, calculate the gradient of the target energy function with respect to the node vectors and control point weights, and update the values ​​of the node vectors and control point weights along the gradient descent direction, while constraining the original shape error of the NURBS surface within an allowable range; stop iterating when the number of iterations reaches a preset maximum value or the change in the target energy function is lower than the convergence threshold; output the optimized node vectors and control point weights, thereby generating a numerically stable optimized NURBS representation suitable for texture mapping and surface subdivision.

[0061] Step S'1024: Establish a bidirectional converter between the parametric model and the NURBS model, and perform on-demand conversion between the two representations according to the dynamic changes in rendering accuracy and performance requirements.

[0062] Specifically, on-demand conversion between the two representations based on dynamic changes in rendering precision and performance requirements can be achieved by: real-time monitoring of the graphics rendering engine's performance metrics (e.g., frame rate) and the user-specified rendering quality level; triggering a conversion decision to a high-precision NURBS representation when the performance metrics fall below a first threshold or the quality level rises above a second threshold; triggering a conversion decision to a high-performance parametric representation when the performance metrics fall below a third threshold or the quality level falls below a fourth threshold; responding to the conversion decision, invoking the corresponding conversion routine in the bidirectional converter (which is based on the mathematical equivalence of the two representations) to perform parameter calculations and data reconstruction, thus completing the conversion of the geometric representation; and synchronously updating the identifiers of the newly generated geometric data objects after conversion to all topologies that reference the original geometric data, ensuring consistency between geometric and topological associations.

[0063] Step S103: Convert the original topology data into a standard topology data structure based on boundary representation for representation and storage.

[0064] If a graphics rendering engine ignores topological information when rendering model files, treating the model only as a discrete set of triangles (e.g., STL format), the high-level structural information of the model will be permanently lost. This results in the inability to distinguish between the model's interior and exterior, hindering precise Boolean operations, model editing, and adaptive simplification. The model loses its engineering semantics and can only be used for visual display, severely limiting its application value. To reconstruct and maintain the topological integrity of the model, the original topological data can be converted into a standard topological data structure based on boundary representation for representation and storage. By converting the original topological data of the model file into a unified and unambiguous boundary representation (BRep), it not only describes the geometry but also clearly defines the connections between shapes. This enables subsequent model operations, analysis, and high-performance rendering (e.g., topology-based edge lighting rendering).

[0065] Specifically, as an embodiment of this application, the conversion of the original topology data into a standard topology data structure based on boundary representation can be achieved through steps S1031 to S1033, as detailed below:

[0066] Step S1031: parse the geometric relationships in the original topology data.

[0067] Step S1032: Reconstruct the geometric relationships in the original topological data into a hierarchical topological structure based on vertices, edges, faces, shells, and volumes.

[0068] Specifically, reconstructing the geometric relationships in the original topological data into a hierarchical topological structure based on vertices, edges, faces, shells, and volumes can be achieved by: introducing a half-edge data structure to accurately describe the directionality of edges and the adjacency relationship with faces. Here, a half-edge is defined by an unsigned integer array storing the corresponding edge identifier and a Boolean value, and the Boolean value is used to indicate whether the direction of the half-edge is consistent with the direction of the original edge; the boundary of a face is defined by combining multiple half-edges connected end to end into a loop; the continuous surface of a geometric entity is defined by combining multiple faces into a shell; and the final three-dimensional geometric object is defined by combining one or more closed shells into a volume.

[0069] Step S1033: Use unsigned integer identifiers to establish the association between topological elements such as vertices, edges, faces, shells, and volumes and standard geometric data.

[0070] Specifically, step S1033 can be implemented as follows: when standard geometric data (i.e., the standard geometric data obtained after processing the original geometric data in step S102) is created and stored in the data structure, a globally unique unsigned integer identifier is assigned to each geometric element (i.e., point, curve, surface, etc.), and the identifier is stored in the data structure header of the geometric element; during the reconstruction of the hierarchical topology, whenever a topology element (i.e., vertex, edge, face, shell, volume, etc.) is created, the following operations are performed: for a vertex, its unsigned integer identifier is read from the data structure header of its associated geometric "point". The topology data structure is constructed by reading and storing the unsigned integer identifier of each topology vertex as its core attribute value. For edges, the unsigned integer identifier is read from the data structure header of the associated geometric "curve" and stored. At the same time, the stored geometric point identifiers of the two topology vertices referenced by the edge are read and stored. For faces, the unsigned integer identifier is read from the data structure header of the associated geometric "surface" and stored. After the topology data structure is constructed, all topology elements are traversed to check whether their stored unsigned integer identifiers point to a real and valid geometric element object to ensure the correctness and completeness of the association.

[0071] In another embodiment of this application, the original topology data can be converted into a standard topology data structure based on boundary representation, which can be achieved through steps S'1031 to S'1033, as detailed below:

[0072] Step S'1031: parse heterogeneous topological data from different geometry engines and extract the implicit relationships between vertices, edges, and faces.

[0073] Step S'1032: Map the extracted relationships into a neutral topological graph structure.

[0074] Step S'1033: Based on the boundary representation method, the topological graph structure is traversed and reconstructed to generate a standardized topological hierarchy structure containing vertices, edges, half-edges, loops, faces, shells, and volumes. Each topological element is precisely associated with standard geometric data through an unsigned integer identifier. Standard geometric data is the standard geometric data obtained after processing the original geometric data in step S102.

[0075] Steps S'1031 to S'1033 described above represent an idealized topology reconstruction process. However, in the real world, the original topology data parsed from different geometry engines may contain defects or inconsistencies. These defects include topology errors and subsequent problems caused by data quality issues. Topology errors may include unclosed boundary loops of faces (gap), an edge shared by three or more faces (non-manifold edge), or broken or missing face patches, etc. If this defective topology data is directly passed to a graphics rendering engine, it may lead to rendering errors (e.g., broken faces, flickering), failure of physical simulation calculations, or inability to perform subsequent editing operations. Therefore, to ensure that the reconstructed standardized topology data structure is inherently consistent, complete, and conforms to geometric modeling rules (e.g., conforms to the manifold assumption), thereby providing high-quality, reliable topology data for the graphics engine, the process of converting the original topology data into a standard topology data structure based on boundary representation through steps S'1031 to S'1033 may further include performing topology consistency verification. This involves checking whether the boundary loops of each face are closed; checking whether each edge is shared by exactly two faces and represented by two half-edges in opposite directions; and initiating a repair routine if non-manifold edges or broken faces are found. This repair routine interpolates based on the continuity of adjacent geometric elements or submits repair suggestions through a user interface. Through topology consistency verification, the system can proactively discover and identify potential defects instead of propagating erroneous data downwards, thus ensuring that the final output standardized model data package is of high quality and reliability. Furthermore, by initiating repair routines, an automated approach to problem-solving (e.g., interpolation based on continuity) is provided, reducing reliance on external manual intervention and improving the automation and robustness of the entire processing flow.

[0076] Furthermore, considering that model data is not static in real-world graphics rendering applications, a core requirement of graphics rendering engines is Level of Detail (LOD), which dynamically switches between models of different precision based on the distance of objects from the camera to ensure rendering efficiency. Therefore, how to maintain the integrity and correctness of the topological structure when dynamically simplifying (reducing the number of faces) or subdividing (increasing the number of faces) the standardized model to adapt to the LOD rendering strategy is a derived technical problem that needs to be solved. To solve this technical problem, the technical solution of this application further includes, after step S'1033 of the above embodiment: in response to the subsequent requirements of the graphics rendering engine for model simplification or subdivision, dynamic operations are performed on the standardized topological hierarchy. That is, when simplifying the model, adjacent faces are merged and their corresponding geometric data and topological links are updated synchronously; when subdividing the model, new edges and vertices are inserted into the topological structure of a specified face, and the affected parent layer shell and volume structures are recursively updated. Because the model simplification process merges adjacent faces and synchronously updates their corresponding geometric data and topological links, the solution no longer modifies the topology or geometry in isolation. Instead, it actively and atomically updates all affected associated data while manipulating the topological structure (merging faces, inserting edges). This ensures that after any dynamic operation, the entire data model (geometry + topology) remains an internally consistent and self-consistent whole. Furthermore, by recursively updating the affected parent-level shell and volume structures, a mechanism to ensure global consistency is introduced. This ensures that changes to a local face can be automatically propagated upwards, updating the boundary information of its shell and volume. This ensures that even after dynamic modifications, the model's high-level semantic information (e.g., "this is an entity") is preserved.

[0077] Step S104: Create, parse, or set the spatial position and orientation information of the model entity and the virtual camera in the world coordinate system.

[0078] Simply setting the origin of the model entity as the world coordinate system origin by default and ignoring camera information in the file, allowing the graphics rendering engine to create the camera at a fixed position, cannot handle complex scene assembly. This is because when a model entity consists of multiple sub-parts (potentially from different files), all parts overlap at the world coordinate system origin, preventing proper assembly. Furthermore, the fixed camera viewpoint cannot reproduce the specific perspective saved in the design intent, resulting in the loss of preset scene state information and a degraded user experience. To address these issues, this application creates, parses, or sets the spatial position and orientation information of model entities and virtual cameras in the world coordinate system. This solution ensures the precise positioning and orientation of model entities within the scene and restores the creator's preset viewing perspective. This is fundamental to assembling multiple models into a correct scene and presenting its design intent, and is necessary for any application scenario that goes beyond the display of a single model.

[0079] Specifically, as an embodiment of this application, creating, parsing, or setting the spatial position and orientation information of the model entity and the virtual camera in the world coordinate system can be as follows: determining whether a local coordinate system has been defined for the model entity in the model file; if no local coordinate system has been defined for the model entity in the model file, then creating a default local coordinate system that coincides with the world coordinate system, i.e., the model coordinate system, and assigning the default local coordinate system to the model entity; if a local coordinate system has been defined for the model entity in the model file, then parsing the origin coordinates and axial vectors of the local coordinate system that has been defined for the model entity, and converting and storing the origin coordinates and axial vectors into a standard data structure; dynamically generating the local coordinate system of the virtual camera, i.e., the camera coordinate system, according to the preset virtual camera parameters or the preset relative position relationship between the virtual camera and the model entity. Here, dynamically generating the local coordinate system of the virtual camera can specifically be as follows: calculating the focal plane position, orientation vector, and upward vector of the virtual camera, and constructing a 4x4 coordinate transformation matrix based on this to transform the points in the camera coordinate system to the world coordinate system.

[0080] Although steps S101 to S104 of the above embodiments have solved the problems of data standardization and compatibility, a standardized, high-precision model data package may incur significant performance overhead due to its unnecessary details when directly used for rendering. Therefore, in order to perform secondary optimization on the standardized high-quality model data without sacrificing visual fidelity, significantly reducing the computational load of the graphics rendering engine, and thus improving rendering efficiency and real-time frame rate, the method may further include, after step S103: simplifying or retopologically processing the standardized geometric and topological data based on the specific needs of the subsequent graphics rendering engine to reduce the computational load; specifically, simplifying or retopologically processing the standardized geometric and topological data based on the specific needs of the subsequent graphics rendering engine may involve dynamically selecting different precision geometric representations or different levels of detail models for rendering based on the estimated pixel size of the model entity in the virtual camera viewport. This solution automates and intelligently implements Level of Detail (LOD) technology, ensuring precise allocation of computing resources: high-precision representations are used for models with large screen area and high visual attention, while low-precision representations are used for models with small screen area and low visual attention. This context-aware adaptive optimization maximizes the balance between rendering quality and performance.

[0081] Specifically, dynamically selecting different geometric representations or levels of detail for rendering based on the estimated pixel size of the model entity in the virtual camera viewport can be achieved through the following steps S1 to S4: Step S1: For the model entity to be rendered, obtain its bounding box information in the world coordinate system, and obtain the current position, orientation, field of view, and target resolution of the virtual camera; Step S2: Project the world space bounding box of the model entity onto the clipping space of the virtual camera, and further convert it to screen space, calculate the pixel area of ​​the region it occupies in the screen space, and use it as its estimated pixel size. Pixel size; Step S3: Compare the estimated pixel size with a set of predefined LOD thresholds. Based on the threshold range it falls within, select a matching representation from multiple pre-generated geometric representations (or models with different levels of detail) of the model entity with different precision for rendering. The smaller the estimated pixel size, the lower the precision or the more simplified the level of detail of the selected geometric representation. Step S4: Switch the geometric data reference in the rendering instruction from the current representation to the new representation selected in step S3, and submit the low-precision or simplified model data to the graphics rendering engine for drawing.

[0082] Step S105: Parse the material properties, surface textures, and animation information in the model file's supplementary information and encapsulate them into the corresponding standard data structures.

[0083] In the field of computer graphics rendering, existing general format conversion processes easily lose rendering-related attributes such as materials, textures, and animations, leading to distorted and unrealistic rendering results. In other words, if only geometric and topological data are converted, ignoring all auxiliary information, or if materials and animations are hard-coded in the graphics rendering engine, the rendering results lose realism (e.g., metal looks like plastic) and cannot reproduce complex animation effects. This shows that hard-coding is completely unscalable; it requires recoding every time a different model is used, losing data-driven flexibility and making automated processing impossible. Therefore, in order to preserve the model's visual attributes and dynamic behavior to the greatest extent, this application can parse the material attributes, surface textures, and animation information in the auxiliary information of the model file and encapsulate them into corresponding standard data structures. This approach can completely and structurally preserve the non-geometric information required for rendering, which can then be passed to the graphics rendering engine, enabling the final rendering result to highly reproduce the appearance and dynamic effects of the original design, which is key to achieving high-quality, high-fidelity rendering.

[0084] Specifically, as an embodiment of this application, parsing the material properties, surface textures, and animation information in the auxiliary information of the model file and encapsulating them into the corresponding standard data structure may involve: parsing the material properties in the model file; mapping parameters related to ambient light, diffuse reflection, specular highlights, roughness, and transparency to a predefined material data structure; parsing texture mapping information and associating the texture mapping information with texture coordinates in standard geometric data; creating a texture object and setting sampling parameters, mapping mode, and Mipmap level for the texture object; parsing animation information, where the animation information includes keyframe sequences, interpolation types, and animation paths; and encapsulating the parsed animation data into an animation data structure, where the animation data structure supports the creation, deletion, modification, and querying of keyframes. Specifically, parsing the animation information may involve: extracting the timestamp of the keyframe, the transformation matrix of the model entity at that moment, the visibility state, transparency, and color information; calculating the model state of the intermediate frame based on the interpolation type of adjacent keyframes, where the interpolation type of adjacent keyframes includes linear interpolation, Bézier curve interpolation, or spline interpolation.

[0085] As another embodiment of this application, parsing the material properties, surface textures, and animation information in the auxiliary information of the model file and encapsulating them into the corresponding standard data structure can also be achieved by: creating a standardized material data structure that supports physical-based rendering; parsing the material parameters in the model file, and uniformly converting parameters that are semantically similar but have different numerical representations in different engines to the parameter space defined by the standardized material data structure through a mapping function, wherein the mapping function is based on the physical property definition of the material to ensure that the rendered visual effect after conversion remains consistent across different engines; providing a runtime interpreter for the standardized material data structure; the runtime interpreter, based on the shader model supported by the target graphics engine, compiling the common material parameters stored in the standardized material data structure in real time to generate the corresponding shader code or parameter block; converting the parsed animation data into a time-axis-based, channelized animation data structure, wherein the transformation, material properties, visibility, and custom properties of the model entity are mapped to independent animation channels respectively; and for the keyframe data of each channel, uniformly standardizing its interpolation type to one of several predefined mathematical interpolation algorithms and storing the necessary parameters for calculating the interpolation.

[0086] Furthermore, to make the static, data-driven animation description "move" and efficiently drive the rendered model to undergo actual, smooth visual changes at runtime, the above embodiment's parsing of material properties, surface textures, and animation information in the model file's supplementary information and encapsulation into corresponding standard data structures may also include: at runtime, driving the animation data structure according to the global timestamp set by the application; for each active animation channel, calculating the attribute value at that moment in real time based on the current timestamp, keyframe, and interpolation type; and synchronously applying the calculated attribute value to the corresponding model entity or material to achieve the playback of the animation effect. This solution transforms animation data from a static storage structure into an executable functional unit. Applications only need to input a global timestamp to automatically obtain the state values ​​of all attributes for the current frame, greatly simplifying the work of the graphics rendering engine. The engine no longer needs to understand the complex internal structure of the animation data (including channels, keyframes, interpolation types, etc.); it only needs to call the function and obtain the result, thus reducing the development complexity and improving efficiency. Furthermore, real-time calculation of attribute values ​​means that calculations occur on demand and dynamically, ensuring precise synchronization between the animation and system time. This avoids the excessive memory consumption that might result from pre-calculating all frames and ensures that the animation accurately responds to interactive operations (e.g., fast forward, slow motion, jumps). In addition, synchronously applying the calculated attribute values ​​to the corresponding model entities or materials ensures that all attributes affected by the animation within a frame (including transformations, colors, transparency, etc.) are calculated and updated based on the same timestamp. This avoids visual tearing and inconsistent states that might occur due to asynchronous calculation and updates, guaranteeing the visual integrity and realism of the animation effect.

[0087] Step S106: Combine the standardized geometric data, topological data, coordinate system information, and auxiliary information into a complete standardized model data package that can be directly used by the graphics rendering engine.

[0088] From the above appendix Figure 1As can be seen from the example of the model data adaptation processing method for the graphics rendering engine, on the one hand, by converting the original geometric and topological data extracted from the model file into a unified standard data structure, the structural differences between different data sources are effectively eliminated, providing a stable and consistent data interface for the upper-level graphics rendering engine. Furthermore, by parsing and encapsulating the material properties, surface textures, and animation information in the model file's supplementary information, the technical bias of losing such supplementary information during the conversion process of existing general standard formats is overcome, ensuring that various information, from physical materials to complex animations, is completely preserved and transmitted to the rendering engine. On the other hand, by creating, parsing, or setting the spatial position and orientation information of the model entity and virtual camera in the world coordinate system, the model's positioning and viewpoint configuration in the scene become more accurate and flexible, reserving interfaces for future integration of more types of geometric engines or rendering attributes, and exhibiting good scalability. Thirdly, by combining the standardized geometry, topology, coordinate system, and supplementary information into a complete standardized model data package, the rendering engine can directly load and use the data without cumbersome format parsing and secondary data processing, thereby reducing preprocessing overhead before rendering and improving the efficiency of the overall rendering pipeline. In summary, the technical solution of this application provides a complete, efficient and directly usable standardized data package for graphics rendering engines by uniformly converting multi-source heterogeneous model data.

[0089] Please see the appendix Figure 2 This application provides a model data adaptation processing device for a graphics rendering engine. The device may include an extraction module 201, a first transformation module 202, a second transformation module 203, a coordinate processing module 204, an auxiliary information processing module 205, and a combination module 206, as detailed below:

[0090] Extraction module 201 is used to import and parse model files from different geometric modeling engines, and extract the original geometric data, original topological data and related information.

[0091] The first conversion module 202 is used to convert the original geometric data into a unified standard geometric data structure for representation and storage.

[0092] The second conversion module 203 is used to convert the original topology data into a standard topology data structure based on boundary representation for representation and storage.

[0093] The coordinate processing module 204 is used to create, parse, or set the spatial position and orientation information of model entities and virtual cameras in the world coordinate system.

[0094] The auxiliary information processing module 205 is used to parse the material properties, surface textures and animation information in the extracted auxiliary information and encapsulate them into the corresponding standard data structure;

[0095] The combination module 206 is used to combine standardized geometric data, topological data, coordinate system information and auxiliary information into a complete standardized model data package that can be directly used by the graphics rendering engine.

[0096] From the above appendix Figure 2 As can be seen from the example of the model data adaptation processing device for the graphics rendering engine, on the one hand, by converting the original geometric and topological data extracted from the model file into a unified standard data structure, the structural differences between different data sources are effectively eliminated, providing a stable and consistent data interface for the upper-level graphics rendering engine. Furthermore, by parsing and encapsulating the material properties, surface textures, and animation information in the model file's supplementary information, the technical bias of losing such supplementary information during the conversion process of existing general standard formats is overcome, ensuring that various information, from physical materials to complex animations, is completely preserved and transmitted to the rendering engine. On the other hand, by creating, parsing, or setting the spatial position and orientation information of the model entity and virtual camera in the world coordinate system, the model's positioning and viewpoint configuration in the scene become more accurate and flexible, reserving interfaces for future integration of more types of geometric engines or rendering attributes, and exhibiting good scalability. Thirdly, by combining the standardized geometry, topology, coordinate system, and supplementary information into a complete standardized model data package, the rendering engine can directly load and use the data without cumbersome format parsing and secondary data processing, thereby reducing preprocessing overhead before rendering and improving the efficiency of the overall rendering pipeline. In summary, the technical solution of this application provides a complete, efficient and directly usable standardized data package for graphics rendering engines by uniformly converting multi-source heterogeneous model data.

[0097] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 3 As shown, the electronic device 3 in this embodiment mainly includes: a processor 30, a memory 31, and a computer program 32 stored in the memory 31 and executable on the processor 30, such as a program for a model data adaptation processing method for a graphics rendering engine. When the processor 30 executes the computer program 32, it implements the steps described in the above embodiment of the model data adaptation processing method for a graphics rendering engine, for example... Figure 1 The steps S101 to S106 are shown. Alternatively, when the processor 30 executes the computer program 32, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 2 The functions of the extraction module 201, the first conversion module 202, the second conversion module 203, the coordinate processing module 204, the auxiliary information processing module 205, and the combination module 206 are shown.

[0098] For example, the computer program 32 for the model data adaptation processing method of the graphics rendering engine mainly includes: importing and parsing model files from different geometric modeling engines, extracting the original geometric data, original topological data, and auxiliary information therein; converting the original geometric data into a unified standard geometric data structure for representation and storage; converting the original topological data into a standard topological data structure based on boundary representation for representation and storage; creating, parsing, or setting the spatial position and orientation information of the model entity and virtual camera in the world coordinate system; parsing the material properties, surface textures, and animation information in the auxiliary information of the model file and encapsulating them into the corresponding standard data structure; and combining the standardized geometric data, topological data, coordinate system information, and auxiliary information into a complete standardized model data package that can be directly used by the graphics rendering engine. The computer program 32 can be divided into one or more modules / units, one or more modules / units are stored in the memory 31 and executed by the processor 30 to complete this application. One or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which are used to describe the execution process of the computer program 32 in the electronic device 3. For example, computer program 32 can be divided into the functions of extraction module 201, first conversion module 202, second conversion module 203, coordinate processing module 204, auxiliary information processing module 205, and combination module 206 (module in the virtual device). The specific functions of each module are as follows: Extraction module 201 is used to import and parse model files from different geometric modeling engines, and extract the original geometric data, original topological data, and auxiliary information; First conversion module 202 is used to convert the original geometric data into a unified standard geometric data structure for representation and storage; Second conversion module 203 is used to... The original topology data is converted into a standard topology data structure based on boundary representation for representation and storage; the coordinate processing module 204 is used to create, parse, or set the spatial position and orientation information of the model entities and virtual cameras in the world coordinate system; the auxiliary information processing module 205 is used to parse the material properties, surface textures, and animation information in the extracted auxiliary information and encapsulate them into the corresponding standard data structure; the combination module 206 is used to combine the standardized geometric data, topology data, coordinate system information, and auxiliary information into a complete standardized model data package that can be directly used by the graphics rendering engine.

[0099] Electronic device 3 may include, but is not limited to, processor 30 and memory 31. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device may also include input / output devices, network access devices, buses, etc.

[0100] The processor 30 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0101] The memory 31 can be an internal storage unit of the electronic device 3, such as a hard disk or RAM. The memory 31 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 31 can include both internal and external storage units of the electronic device 3. The memory 31 is used to store computer programs and other programs and data required by the electronic device. The memory 31 can also be used to temporarily store data that has been output or will be output.

[0102] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed. That is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above-described device can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0103] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0104] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0105] In the embodiments provided in this application, it should be understood that the disclosed apparatus / device and method can be implemented in other ways. For example, the apparatus / device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0106] 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0107] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0108] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a storage medium. Based on this understanding, all or part of the processes in the above-described embodiments of this application can also be implemented by a computer program instructing related hardware. The computer program for the model data adaptation processing method for the graphics rendering engine can be stored in a storage medium. When the computer program is executed by a processor, it can implement the steps of the above-described method embodiments, namely, importing and parsing model files from different geometric modeling engines, extracting the original geometric data, original topological data, and auxiliary information therein; converting the original geometric data into a unified standard geometric data structure for representation and storage; converting the original topological data into a standard topological data structure based on boundary representation for representation and storage; creating, parsing, or setting the spatial position and orientation information of the model entity and virtual camera in the world coordinate system; parsing the material properties, surface textures, and animation information in the auxiliary information of the model file and encapsulating them into the corresponding standard data structure; and combining the standardized geometric data, topological data, coordinate system information, and auxiliary information into a complete standardized model data package that can be directly used by the graphics rendering engine. Computer programs include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. Storage media can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the contents of storage media can be appropriately added or removed according to the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, storage media do not include electrical carrier signals and telecommunication signals.

[0109] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application. The specific embodiments described above further illustrate the purpose, technical solutions, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the protection scope of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for adapting model data for a graphics rendering engine, characterized in that, The method includes: Import and parse model files from different geometric modeling engines, and extract the original geometric data, original topological data and ancillary information; The original geometric data is converted into a unified standard geometric data structure for representation and storage; The original topology data is converted into a standard topology data structure based on boundary representation for representation and storage; Create, parse, or set the spatial position and orientation information of model entities and virtual cameras in the world coordinate system; The material properties, surface textures, and animation information in the supplementary information are parsed and encapsulated into the corresponding standard data structures; The standardized geometric data, topological data, coordinate system information, and auxiliary information are combined into a complete standardized model data package that can be directly used by the graphics rendering engine.

2. The model data adaptation processing method for a graphics rendering engine according to claim 1, characterized in that, The step of converting the original geometric data into a unified standard geometric data structure for representation includes: Determine whether the curves or surfaces in the original geometric data are simple geometric entities that can be defined by a single mathematical expression; If so, a predefined basic geometric model data structure is used to simplify its representation; otherwise, a non-uniform rational B-spline NURBS model is used to accurately represent it, and a method for mutual conversion between the basic geometric model and the NURBS model is provided.

3. The model data adaptation processing method for a graphics rendering engine according to claim 2, characterized in that, The process of calling a predefined basic geometric model data structure for simplified representation and storage includes: For a circle or ellipse, store its center, the direction of the principal axis of the local coordinate system, and the radius or major and minor axis information; For a straight line, store its starting point, direction vector, and length information; For a quadric surface, store its center point, parametric equation identifier, and corresponding parameter values.

4. The model data adaptation processing method for a graphics rendering engine according to claim 1, characterized in that, The step of converting the original topology data into a standard topology data structure based on boundary representation includes: Analyze the geometric relationships in the original topological data; The aforementioned relationships are reconstructed into a hierarchical topology based on vertices, edges, faces, shells, and volumes; The association between the topological elements such as vertices, edges, faces, shells, and volumes and standard geometric data is established using unsigned integer identifiers.

5. The model data adaptation processing method for a graphics rendering engine according to claim 1, characterized in that, The process of creating, resolving, or setting the spatial position and orientation information of model entities and virtual cameras in the world coordinate system includes: Determine whether a clearly defined local coordinate system has been defined for the model entity in the model file; If no explicit local coordinate system is defined for the model entity in the model file, a default local coordinate system that coincides with the world coordinate system is created and the default local coordinate system is assigned to the model entity. If a local coordinate system has been defined for the model entity in the model file, then the origin coordinates and axial vectors of the local coordinate system defined for the model entity are parsed, and the origin coordinates and axial vectors are converted and stored as a standard data structure. Based on preset virtual camera parameters or the relative positional relationship between the virtual camera and the model entity, a local coordinate system of the virtual camera is dynamically generated. The dynamic generation of the local coordinate system of the virtual camera includes: calculating the focal plane position, orientation vector, and up vector of the virtual camera, and constructing a 4x4 coordinate transformation matrix based on this to transform points in the camera coordinate system to the world coordinate system.

6. The model data adaptation processing method for a graphics rendering engine according to claim 1, characterized in that, The process of parsing the material properties, surface textures, and animation information in the supplementary information and encapsulating them into the corresponding standard data structure includes: Parse the material properties in the model file; Parameters related to ambient light, diffuse reflection, specular reflection, roughness, and transparency are mapped to a predefined material data structure; The texture mapping information is parsed, and the texture mapping information is associated with the texture coordinates in the standard geometric data; Create a texture object and set the sampling parameters, mapping mode, and Mipmap level for the texture object; Parse the animation information, which includes keyframe sequence, interpolation type, and animation path; The parsed animation data is encapsulated into an animation data structure, which supports the creation, deletion, modification, and querying of keyframes.

7. The model data adaptation processing method for a graphics rendering engine according to claim 6, characterized in that, The parsed animation information includes: Extract the timestamp of the keyframe, the transformation matrix of the model entity at that moment, the visibility state, transparency and color information; The model state of the intermediate frame is calculated based on the interpolation type of the adjacent keyframes. The interpolation type includes linear interpolation, Bézier curve interpolation, or spline interpolation.

8. A model data adaptation and processing device for a graphics rendering engine, characterized in that, The device includes: The extraction module is used to import and parse model files from different geometric modeling engines, extracting the original geometric data, original topological data, and ancillary information. The first conversion module is used to convert the original geometric data into a unified standard geometric data structure for representation and storage. The second conversion module is used to convert the original topology data into a standard topology data structure based on boundary representation for representation and storage. The coordinate processing module is used to create, parse, or set the spatial position and orientation information of model entities and virtual cameras in the world coordinate system. An auxiliary information processing module is used to parse the material properties, surface textures, and animation information in the auxiliary information and encapsulate them into the corresponding standard data structure. The combination module is used to combine standardized geometric data, topological data, coordinate system information, and auxiliary information into a complete standardized model data package that can be directly used by the graphics rendering engine.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images