ODB++ to SVG rendering method, device, equipment and medium

Abstract

The application discloses an ODB++ to SVG rendering method, device, equipment and medium, and relates to the technical field of electronic design automation. The method comprises the following steps: analyzing an ODB++ project directory tree, extracting the graphic metadata, spatial transformation parameters and step repeat array parameters of production steps and the nested sub-production steps; converting each graphic into an internal object and mapping it into a corresponding SVG label; baking the graphic coordinates in the sub-production step into the parent coordinate system through combined transformation according to the transformation parameters; combining the SVG label, the transformed coordinates and the rendering color to generate a reusable graphic block; calling the corresponding reusable graphic block in a translation reference manner for each instance of the step repeat array to generate an SVG file. The application can directly view the ODB++ board shape in the browser without relying on third-party CAM software, and solves the problems of software dependence, high operation threshold, cross-system sharing difficulty and inconvenience of confirming the board shape on the production line.

Description

Technical Field

[0001] This invention relates to the field of electronic design automation technology, specifically to a rendering method, apparatus, device, and medium for converting ODB++ to SVG. Background Technology

[0002] ODB++ is a widely used engineering data exchange format in the printed circuit board (PCB) industry, used to transfer complete PCB production data between computer-aided design (CAD) or computer-aided manufacturing (CAM) systems.

[0003] Currently, viewing ODB++ data in the industry requires relying on professional third-party CAM software, which presents the following problems:

[0004] 1. Heavy software dependency: Each browser terminal must have the complete CAM software installed, which has requirements for the operating system's graphics library, and new employees or production line terminals cannot quickly connect to it;

[0005] 2. Significantly high learning curve: CAM software is designed for creation rather than browsing, and operators need professional training to be able to quickly access information at all levels.

[0006] 3. Difficulty in cross-system sharing: The CAM software interface is a closed, proprietary format that cannot be directly previewed in browsers, document systems, or instant messaging.

[0007] 4. Inconvenient for production line to confirm board shape: When confirming board shape and judging process parameters, production line, process and engineering personnel rely on manual communication or downloading data and then opening CAM software to check, which is inefficient and prone to errors.

[0008] 5. AI large-scale model analysis of PCB board shape requires opening ODB++ files layer by layer and capturing them as JPG images using third-party CAM software. This method relies on professional software and is cumbersome to operate.

[0009] In summary, existing technologies suffer from problems such as heavy software dependence, high operational barriers, difficulty in cross-system sharing, and inconvenience in confirming board shape on the production line. Summary of the Invention

[0010] The technical problem to be solved by this invention is that the existing ODB++ data viewing requires professional third-party CAM software, which leads to problems such as heavy software dependence, high operation threshold, difficulty in cross-system sharing, and inconvenience in confirming board shape on the production line. The purpose is to provide a rendering method, device, equipment and medium for ODB++ to SVG, which solves the above problems.

[0011] This invention is achieved through the following technical solution:

[0012] In a first aspect, the present invention provides a rendering method from ODB++ to SVG, comprising:

[0013] Parse the ODB++ project directory tree to extract the graph data of the production steps and their nested sub-production steps, as well as the spatial transformation parameters and step repeat array parameters of each production step.

[0014] Each primitive in ODB++ is converted into an internal object, and the geometric parameters, type identifier, and attribute information of each internal object are recorded. Each primitive is then mapped to a corresponding scalable vector graphic SVG tag. The attribute information includes polarity attribute, layer name, and production step name.

[0015] Based on the spatial transformation parameters of each sub-production step, the coordinates of each element within that sub-production step are baked into the parent coordinate system through a combination transformation to obtain the transformed coordinates.

[0016] Reusable graphic blocks are generated based on the SVG tags, transformed coordinates, and rendered colors of each graphic element; wherein the rendered colors are determined based on the polarity attribute of the graphic element.

[0017] For each instance of the step-repeating array, the corresponding reusable graphic block is invoked using a translation reference method to generate an SVG file.

[0018] Optionally, the primitives include geometric primitives, text primitives, and symbol primitives; mapping each primitive to a corresponding SVG tag includes:

[0019] For geometric primitives, generate corresponding SVG tags based on their geometric parameters;

[0020] For text primitives, generate corresponding SVG tags based on their character content;

[0021] For symbolic primitives, their symbol names are parsed using precise regular expressions and mapped to corresponding SVG tags according to their shapes.

[0022] Optionally, the geometric primitives include arc primitives; the SVG tags corresponding to the arc primitives include large arc tags. and sweeping direction The step of generating corresponding SVG tags for geometric primitives based on their geometric parameters includes:

[0023] Get the starting coordinates of the arc primitive End point coordinates Coordinates of the center of the circle and directional signs;

[0024] Calculate the radius of the arc ;

[0025] Calculate the starting angle ;

[0026] Calculate the endpoint angle ;

[0027] Calculate the sweep angle If the arc primitive is clockwise and delta>0, then subtract 2π from delta; if the arc primitive is counterclockwise and delta<0, then add 2π to delta.

[0028] like ,but The value is 1 if it is set to 1, otherwise the value is 0.

[0029] like ,but The value is 1 otherwise; if a mirror flip exists, the sweep value is inverted.

[0030] Optionally, the rendered color is determined in the following way:

[0031] For primitives with a positive polarity, the specified color is determined as the rendering color;

[0032] For primitives with negative polarity, the background color is determined as the rendering color.

[0033] Optionally, the spatial transformation parameters include rotation angle, mirror direction, and coordinate offset;

[0034] The step of baking the coordinates of each element within a sub-production step to the parent coordinate system through a combination transformation based on the transformation parameters of each sub-production step to obtain the transformed coordinates includes:

[0035] For each element within each sub-production step, perform the following operations:

[0036] Subtract the coordinates of the reference point from the coordinates of the graphic element;

[0037] The graphic elements are mirrored and flipped according to the mirror direction;

[0038] The coordinates of the graphic element are rotated around the reference point according to the rotation angle.

[0039] The coordinates of the graphic element are added with the offset based on the coordinate offset.

[0040] Optionally, the method further includes optimizing the generated SVG file, wherein the optimization methods include: removing identical element rows within the same graphic group, truncating floating-point precision to three decimal places, and removing redundant default attributes.

[0041] Optionally, the method further includes:

[0042] The ODB++ to SVG rendering method is encapsulated as an intelligent agent, providing a unified interface to enable large AI models to call the intelligent agent through the unified interface to obtain the SVG file and use it for automated process judgment; the unified interface supports output filtering by production step or by layer.

[0043] Secondly, the present invention provides an ODB++ to SVG rendering apparatus, comprising:

[0044] The parsing module is used to parse the ODB++ project directory tree, extract the graph data of the production steps and their nested sub-production steps, as well as the spatial transformation parameters and step repeat array parameters of each production step.

[0045] The conversion module is used to convert each primitive in ODB++ into an internal object, record the geometric parameters, type identifier and attribute information of each internal object, and map each primitive to the corresponding SVG tag; the attribute information includes polarity attribute, layer name, and production step name.

[0046] The baking module is used to bake the coordinates of each element within a sub-production step to the parent coordinate system through combination transformation based on the spatial transformation parameters of each sub-production step, thereby obtaining the transformed coordinates.

[0047] A graphics generation module is used to generate reusable graphic blocks based on the SVG tags, transformed coordinates, and rendering colors of each graphic element; wherein the rendering colors are determined based on the polarity attribute of the graphic element.

[0048] The file generation module is used to call the corresponding reusable graphic block for each instance of the step repeating array in a translational reference manner to generate an SVG file.

[0049] Thirdly, the present invention provides a computer device, the computer device including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the ODB++ to SVG rendering method as described in any one of the first aspects.

[0050] Fourthly, the present invention provides a computer-readable storage medium storing a computer program, wherein a processor executes the computer program to implement the ODB++ to SVG rendering method as described in any one of the first aspects.

[0051] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0052] This application provides a rendering method from ODB++ to SVG. The method parses the ODB++ project directory tree, extracts the graphic data, spatial transformation parameters, and step-repetition array parameters of the production steps and their nested sub-production steps; converts each graphic element into an internal object and maps it to the corresponding Scalable Vector Graphics (SVG) tag; bakes the coordinates of the graphic elements within the sub-production steps to the parent coordinate system through a combination transformation based on the transformation parameters; determines the rendering color based on the polarity attribute of the graphic element, and generates reusable graphic blocks by combining the SVG tags and the transformed coordinates; and calls the corresponding reusable graphic block for each instance of the step-repetition array using a translation reference method to generate an SVG file. This invention does not rely on third-party CAM software, requires no CAM software installation, and requires no professional training. The SVG file can be viewed simply by opening it in a browser. The SVG file can be directly embedded in HTML web pages, instant messaging tools such as DingTalk and WeChat, enterprise knowledge bases, and email content, enabling ODB++ project data to be conveniently viewed and shared in various scenarios, breaking down the circulation barriers caused by the closed format of traditional CAM software. Attached Figure Description

[0053] To more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be considered as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort. In the drawings:

[0054] Figure 1 A flowchart illustrating the ODB++ to SVG rendering method provided in this application embodiment;

[0055] Figure 2 This is a schematic diagram of the structure of the ODB++ to SVG rendering apparatus provided in the embodiments of this application. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the embodiments and accompanying drawings. The illustrative embodiments and descriptions of this invention are only for explaining this invention and are not intended to limit this invention.

[0057] Before introducing the ODB++ to SVG rendering method provided in this application, let's first introduce ODB++. ODB++ project files are organized in a directory tree structure. An ODB++ project file consists of several production steps (Steps), each Step can nest sub-Steps, and each Step is mounted with a Layer. Each Layer consists of a large collection of Features. Each Step can have spatial transformation attributes relative to its parent Step, such as rotation angle, mirror direction, and coordinate offset, and can be repeated in an array within a region through Step-Repeat.

[0058] The following is about Figure 1 The ODB++ to SVG rendering method is introduced.

[0059] S1. Parse the ODB++ project directory tree, extract the graph data of the production steps and their nested sub-production steps, as well as the spatial transformation parameters and step repeat array parameters of each production step.

[0060] In the specific implementation process, the ODB++ project files are organized in a directory tree structure. The ODB++ project directory tree is read to identify the nesting relationship between Step and Step-Repeat. The Layer list under each Step and the corresponding spatial transformation parameters (rotation angle, mirror direction, coordinate offset) and Step-Repeat array parameters (horizontal repeat number nx, vertical repeat number ny, horizontal step dx, vertical step dy) are extracted.

[0061] The key objects produced by the above parsing operation include:

[0062] matrix: Engineering origin and unit conversion parameters;

[0063] steps: A list of sub-Steps and their transformation parameters, recording the rotation angle, mirror direction, and coordinate offset of each sub-Step relative to its parent Step;

[0064] features: A collection of primitive records for each layer, containing the geometric parameters, type identifier, and attribute information of each primitive;

[0065] attrlist: A list of layer attributes that records the layer's polarity (positive / negative) and drill identifier (drl).

[0066] symbols: A custom symbol library containing user-defined symbol graphic data.

[0067] S2. Convert each primitive in ODB++ into an internal object, record the geometric parameters and attribute information of each internal object, and map each primitive to the corresponding SVG tag.

[0068] In the specific implementation process, the primitives include geometric primitives (points, lines, surfaces, arcs), text primitives (characters), and symbol primitives (built-in symbols and custom symbols). The primitives extracted from S1 are converted into Java internal objects, including line segment (Xian) objects, surface (Mian) objects, arc (YuanHu) objects, symbol (FuHao) objects, and character (WenZi) objects. Each internal object records its geometric parameters, type identifier, and attribute information, including polarity, layer name, step name, symbol name, and net name.

[0069] In one possible embodiment, for geometric primitives, corresponding SVG tags are generated based on their geometric parameters; for text primitives, corresponding SVG tags are generated based on their character content; and for symbol primitives, their symbol names are parsed using precise regular expressions and mapped to corresponding SVG tags according to their shapes.

[0070] In practical implementation, the ODB++ standard defines the following 19 built-in symbols:

[0071] Table 1

[0072]

[0073] For the 19 built-in symbols mentioned above, an exact matching strategy (using the full match pattern of regular expressions) is employed to parse their symbol names, avoiding mismatches due to prefixes. For example, "rect10" should match a rectangle, not "r10" (circle). During parsing, the geometric parameters required for the SVG element are calculated based on the numerical parameters in the symbol name (such as radius, width, height, chamfer value, etc.). After parsing, the symbol primitives are mapped to their corresponding SVG tags according to their shapes. Through this exact regular expression matching and classification mapping, various symbol primitives in ODB++ are accurately converted into their corresponding SVG graphic elements, ensuring accurate shape reproduction.

[0074] In one possible embodiment, the geometric primitives include arc primitives; the SVG tag corresponding to the arc primitives includes a large arc symbol. And the sweep direction; for geometric primitives, the steps to generate corresponding SVG tags based on their geometric parameters include:

[0075] S2.1 Obtain the starting coordinates of the arc element. End point coordinates Coordinates of the center of the circle And direction markings (Y / N); Y indicates clockwise direction, N indicates counterclockwise direction;

[0076] S2.2 Calculate the starting angle ;

[0077] S2.3 Calculate the endpoint angle ;

[0078] S2.4 Calculate the sweep angle If the arc primitive is clockwise and delta > 0, then subtract 2π from delta; if the arc primitive is counterclockwise and delta < 0, then... In addition ;

[0079] S2.5, if ,but A value of 1 indicates that the arc sweep angle is greater than 1. If the arc sweep angle is less than or equal to 180°, select the minor arc; otherwise, the value is 0 (meaning the arc sweep angle is less than or equal to 180°, select the minor arc).

[0080] S2.6, if ,but The value is 1 (indicating clockwise direction), otherwise it is 0 (indicating counterclockwise direction); if a mirror flip exists, then... Invert it again;

[0081] It should be noted that before executing S2.3, when the difference between the starting point coordinates and the ending point coordinates of the arc element is less than a preset threshold and At that time, the arc primitive is identified as a full circle, and the arc primitive is split into two. For each half-arc, execute S2.3-S2.7.

[0082] S3. Based on the transformation parameters of each sub-production step, the coordinates of each element within the sub-production step are baked to the parent coordinate system through combination transformation to obtain the transformed coordinates.

[0083] In one possible embodiment, for each element within each sub-production step, the following operation is performed:

[0084] Subtract the coordinates of the reference point from the coordinates of the graphic element;

[0085] Mirror the primitives according to the mirror direction;

[0086] The coordinates of the graphic element are rotated around the reference point according to the rotation angle;

[0087] The coordinates of the graphic element are adjusted by adding the offset amount based on the coordinate offset.

[0088] In the specific implementation process, for the child Step referenced by Step-Repeat, the coordinates of each primitive within it are baked into the parent coordinate system through a combination of transformations: "subtracting the reference point → mirror flipping → rotating around the reference point → adding offset". When performing mirror flipping, the X and / or Y coordinates of the primitives are inverted according to the mirror direction, the sweep direction of the arc primitives is inverted, and the angle of the symbol primitives is corrected to the supplementary angle.

[0089] The calculation method for supplementary angles depends on the mirror direction: for horizontal mirroring, the sign angle is the difference between 180° and the original angle. For vertical mirroring, the sign angle is the negative of the original angle, i.e., -angle; for bidirectional mirroring, the sign angle is the sum of 180° and the original angle, i.e. .

[0090] For stepped repeating arrays, based on the number of horizontal repeats... Number of vertical repetitions Loop through the array, and for the array instance in row i and column j, its offset is... ;in, , .

[0091] S4. Generate reusable graphic blocks based on the SVG tags, transformed coordinates, and rendered colors corresponding to each graphic element.

[0092] In the specific implementation process, the SVG tag (shape type) determined in S2, the transformed coordinates (position information) obtained in S3, and the rendering color (color information) determined according to the polarity attribute of the primitive are combined to generate a complete reusable graphic block (i.e., <g>(block), stored in SVG <defs>area.

[0093] in, <defs>In the SVG standard, this is an element used to store reusable graphic definitions, stored in... <defs>The graphic blocks in the image are not displayed directly on the canvas, but rather through... <use>The tag is rendered at the specified position after being referenced. <g>It is a container element in the SVG standard used to combine multiple graphic elements into a single logical unit, making it easy to reference and transform them as a whole.

[0094] In one possible embodiment, the rendering color is determined based on the polarity attribute of the primitive: for primitives with a positive polarity attribute, a specified color is determined as the rendering color; for primitives with a negative polarity attribute, the background color is determined as the rendering color.

[0095] In the specific implementation process, each primitive object has a polarity (denoted as zf). During rendering, for face (Mian) objects and symbol (FuHao) objects: if zf is true (positive), the fill color and stroke color are both set to the specified color; if zf is false (negative), the fill color and stroke color are both set to the background color (white); for line segment (Xian) objects: if zf is true (positive), the line segment color is set to the specified color; if zf is false (negative), the line segment color is set to the background color (white).

[0096] It should be noted that this application achieves the negative "cutout" effect by filling the background color; that is, the graphic in the negative area is filled and outlined in white, which is visually equivalent to a real cutout. This method does not use SVG masks or clip paths, avoiding the browser performance overhead caused by mask rendering. It is especially suitable for single-layer rendering scenarios, and can significantly improve rendering performance while ensuring rendering effect.

[0097] S5. For each instance of the step-repeating array, call the corresponding reusable graphic block using translation reference to generate an SVG file.

[0098] In the specific implementation process, the sub-production steps in the step-repeat array are compressed by block copying to reduce the size of the final SVG file: when parsing the step-repeat array, the deduplication key is composed of the sub-production step name, rotation angle, and mirror direction. The same combination is baked and rendered only once. All primitives inside the sub-production step are treated as a whole and their coordinates are transformed at once to generate complete graphic data and store it. <defs>Region; the location of each instance in the array is accessed via... <use>The tag references the corresponding reusable graphic block in a pure translation manner without rotation or mirror transformation to avoid browser compatibility issues with SVG rotation rendering; when a sub-production step fails to load or bake, the exception is caught separately and the step is skipped to continue processing other steps, ensuring that the failure of a single step does not affect the export of the overall SVG file.

[0099] Using the method described above, each instance in the step-repeating array is referenced using a translation method to call the corresponding reusable graphic block. All scalable vector graphic elements corresponding to these primitives are combined to generate the final SVG file. This SVG file can be directly opened and viewed in a browser without relying on any third-party CAM software.

[0100] When generating the aforementioned SVG files, to balance rendering accuracy and display adaptation, this application uniformly processes the size and coordinates of each graphic element. Specifically, all ODB++ dimensions are in mil (0.001 inches), which are uniformly converted to inches (×0.001) during rendering, and then drawn with 1:1 integer coordinates at 10000 times the precision. <g>Adapt the target canvas size using the scaling transformation (transform="scale(finalScale)").

[0101] In one possible embodiment, the generated SVG file is optimized, wherein the optimization methods include: removing identical element rows within the same graphic group, truncating floating-point precision to three decimal places, and removing redundant default attributes.

[0102] In the actual implementation process, the generated SVG files undergo the following secondary optimization processing before output to further reduce file size and improve browser parsing efficiency:

[0103] (1) Deduplication within the same frame: Maintain a group of graphics <g>Stack, each layer of graphics group <g>Maintain a separate deduplication set. For each SVG element row to be output, first normalize it (remove redundant attributes such as stroke-width="1"), then compare the normalized element row with existing element rows in the deduplication set. If they are exactly the same, skip the element row to avoid duplicate output; if they are different, output the element row and add it to the deduplication set. In this way, identical redundant element rows within the same graphic group are eliminated.

[0104] (2) Floating-point precision truncation: All floating-point values ​​in the SVG file are truncated to retain only three decimal places, effectively reducing the file size while maintaining sufficient drawing precision.

[0105] (3) Removal of redundant default attributes: Remove redundant attributes with default values ​​from SVG elements, such as stroke-width="1". When the stroke width of an element is the default value, the attribute is removed directly, and the browser will automatically use the default value when rendering, thereby reducing unnecessary attribute declarations and further simplifying the SVG file.

[0106] In one possible embodiment, the ODB++ to SVG rendering method described above is encapsulated as a skill, providing a unified interface. This interface supports filtering output by production step name or layer name, with the output format being SVG fragments that can be embedded in HTML or standalone SVG files.

[0107] After the agent is connected to the AI ​​big model, the AI ​​big model can be directly invoked through natural language commands. For example, if a user inputs "Render the L1 layer of S040048882A00 for me," the AI ​​big model parses the part number and layer number parameters in the command, passes in the corresponding filtering parameters through the agent's unified interface, the agent automatically locates the ODB++ project file path, executes the rendering steps S1 to S5 mentioned above, and returns the corresponding SVG fragment. The AI ​​big model then embeds the SVG fragment in its response and presents it to the user.

[0108] In summary, existing technologies lack a complete, lightweight, and embeddable browser rendering solution for ODB++ to SVG. This application provides an ODB++ to SVG rendering method, which has been implemented and is running in an internal system data interface. Its main entry method receives JSON-formatted input parameters (including the ODB++ path, job name, layer list, step name, etc.). By traversing the matrix structure, it calls the ODB++ to SVG rendering method provided in this application for each combination of production steps and layers, outputting an independent SVG file. The output directory can be flexibly specified by parameters. This method has been practically applied and verified in scenarios such as rapid confirmation of production line board shapes, determination of process parameters, and unified dashboard layout within the engineering internal system, effectively improving production line workflow efficiency and process determination accuracy.

[0109] This application provides a crucial technological bridge for AI large-scale models to understand and analyze PCB board shape data by converting ODB++ engineering data into standard SVG vector graphics. The SVG files generated by this application are in a structured vector format, which is supported by all mainstream AI large-scale models for direct parsing and understanding. This allows AI large-scale models to directly read the precise geometric parameters, polarity attributes, and layer structure of each layer of the circuit board, providing a data foundation for intelligent application scenarios such as AI-assisted process review, automatic determination of trace compliance, and identification of abnormal copper distribution, thus promoting the PCB manufacturing industry's transformation towards AI-driven intelligent manufacturing.

[0110] Based on the same inventive concept, please refer to Figure 2 This application also provides an ODB++ to SVG rendering apparatus, the apparatus comprising:

[0111] The parsing module is used to parse the ODB++ project directory tree, extract the graph data of the production steps and their nested sub-production steps, as well as the spatial transformation parameters and step repeat array parameters of each production step.

[0112] The conversion module is used to convert each primitive in ODB++ into an internal object, record the geometric parameters, type identifier and attribute information of each internal object, and map each primitive to the corresponding SVG tag; the attribute information includes polarity attribute, layer name, and production step name.

[0113] The baking module is used to bake the coordinates of each element within a sub-production step to the parent coordinate system through combination transformation based on the spatial transformation parameters of each sub-production step, thereby obtaining the transformed coordinates.

[0114] The graphics generation module is used to generate reusable graphic blocks based on the SVG tags, transformed coordinates, and rendered colors of each graphic element; wherein, the rendered color is determined according to the polarity attribute of the graphic element.

[0115] The file generation module is used to call the corresponding reusable graphic block for each instance of the step repeating array in a translational reference manner to generate an SVG file.

[0116] Optionally, the primitives include geometric primitives, text primitives, and symbol primitives; the conversion module is specifically used for:

[0117] For geometric primitives, generate corresponding SVG tags based on their geometric parameters;

[0118] For text primitives, generate corresponding SVG tags based on their character content;

[0119] For symbolic primitives, their symbol names are parsed using precise regular expressions and mapped to corresponding SVG tags according to their shapes.

[0120] Optionally, geometric primitives include arc primitives; the corresponding SVG tags for arc primitives include large arc tags. and sweeping direction The conversion module is specifically used for:

[0121] Get the starting coordinates of the arc primitive End point coordinates Coordinates of the center of the circle and directional signs;

[0122] Calculate the radius of the arc ;

[0123] Calculate the starting angle ;

[0124] Calculate the endpoint angle ;

[0125] Calculate the sweep angle If the arc primitive is clockwise and delta > 0, then... Subtract If the arc primitive is in a counterclockwise direction and Then In addition ;

[0126] like ,but The value is 1 if it is set to 1, otherwise the value is 0.

[0127] like ,but The value is 1 if it is true, and 0 otherwise; if a mirror flip exists, then... Then invert it.

[0128] Optionally, the rendering color is determined as follows:

[0129] For primitives with a positive polarity, the specified color is determined as the rendering color;

[0130] For primitives with negative polarity, the background color is determined as the rendering color.

[0131] Optional spatial transformation parameters include rotation angle, mirror direction, and coordinate offset; the baking module is specifically used for:

[0132] For each element within each sub-production step, perform the following operations:

[0133] Subtract the coordinates of the reference point from the coordinates of the graphic element;

[0134] Mirror the primitives according to the mirror direction;

[0135] The coordinates of the graphic element are rotated around the reference point according to the rotation angle;

[0136] The coordinates of the graphic element are adjusted by adding the offset amount based on the coordinate offset.

[0137] Optionally, the file generation module is also used to optimize the generated SVG file. Optimization methods include: removing identical element rows within the same graphic group, truncating floating-point precision to three decimal places, and removing redundant default attributes.

[0138] Optionally, the device further includes a packaging module, which is used for:

[0139] The ODB++ to SVG rendering method is encapsulated as an intelligent agent, providing a unified interface to enable large AI models to call the intelligent agent through the unified interface, obtain SVG files, and use them for automated process judgment; the unified interface supports output filtering by production step or by layer.

[0140] It should be noted that each module in the ODB++ to SVG rendering device in this embodiment corresponds one-to-one with each step in the ODB++ to SVG rendering method in the aforementioned embodiment. Therefore, the specific implementation of this embodiment can refer to the implementation of the aforementioned ODB++ to SVG rendering method, and will not be repeated here.

[0141] Based on the same inventive concept, this application also provides a computer device, which includes a processor, a memory, and a computer program stored in the memory. The computer program is executed by the processor to implement the aforementioned ODB++ to SVG rendering method.

[0142] Based on the same inventive concept, this application also provides a computer storage medium storing a computer program, which is executed by a processor to implement the aforementioned ODB++ to SVG rendering method.

[0143] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a device including one or any combination of the above-mentioned memories. The computer may be a variety of computing devices, including smart terminals and servers.

[0144] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0145] As an example, executable instructions may, but do not necessarily, correspond to files in the file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborative files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0146] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0147] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0148] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.< / g> < / g> < / g> < / use> < / defs> < / g> < / use> < / defs> < / defs> < / defs> < / g>

Claims

1. A rendering method from ODB++ to SVG, characterized in that, include: Parse the ODB++ project directory tree to extract the graph data of the production steps and their nested sub-production steps, as well as the spatial transformation parameters and step repeat array parameters of each production step. Each primitive in ODB++ is converted into an internal object, and the geometric parameters, type identifier, and attribute information of each internal object are recorded. Each primitive is then mapped to a corresponding scalable vector graphic SVG tag. The attribute information includes polarity attribute, layer name, and production step name. Based on the spatial transformation parameters of each sub-production step, the coordinates of each element within that sub-production step are baked into the parent coordinate system through a combination transformation to obtain the transformed coordinates. Reusable graphic blocks are generated based on the SVG tags, transformed coordinates, and rendered colors of each graphic element; wherein the rendered colors are determined based on the polarity attribute of the graphic element. For each instance of the step-repeating array, the corresponding reusable graphic block is invoked using a translation reference method to generate an SVG file.

2. The ODB++ to SVG rendering method according to claim 1, characterized in that, The primitives include geometric primitives, text primitives, and symbol primitives; mapping each primitive to its corresponding SVG tag includes: For geometric primitives, generate corresponding SVG tags based on their geometric parameters; For text primitives, generate corresponding SVG tags based on their character content; For symbolic primitives, their symbol names are parsed using precise regular expressions and mapped to corresponding SVG tags according to their shapes.

3. The ODB++ to SVG rendering method according to claim 2, characterized in that, The geometric primitives include arc primitives; the SVG tags corresponding to the arc primitives include large arc tags. and sweeping direction ; The step of generating corresponding SVG tags for geometric primitives based on their geometric parameters includes: Get the starting coordinates of the arc primitive End point coordinates Coordinates of the center of the circle and directional signs; Calculate the radius of the arc ; Calculate the starting angle ; Calculate the endpoint angle ; Calculate the sweep angle If the arc primitive is clockwise and delta > 0, then... Subtract ; If the arc primitive is in a counter-clockwise direction and Then In addition ; like ,but The value is 1 if it is set to 1, otherwise the value is 0. like ,but The value is 1 if it is true, and 0 otherwise; if a mirror flip exists, then... Then invert it.

4. The ODB++ to SVG rendering method according to claim 1, characterized in that, The rendered color is determined in the following way: For primitives with a positive polarity, the specified color is determined as the rendering color; For primitives with negative polarity, the background color is determined as the rendering color.

5. The ODB++ to SVG rendering method according to claim 1, characterized in that, The spatial transformation parameters include rotation angle, mirror direction, and coordinate offset; the step of baking the coordinates of each element within a sub-production step to the parent coordinate system through a combination transformation based on the transformation parameters of each sub-production step to obtain the transformed coordinates includes: For each element within each sub-production step, perform the following operations: Subtract the coordinates of the reference point from the coordinates of the graphic element; The graphic elements are mirrored and flipped according to the mirror direction; The coordinates of the graphic element are rotated around the reference point according to the rotation angle. The coordinates of the graphic element are added with the offset based on the coordinate offset.

6. The ODB++ to SVG rendering method according to claim 1, characterized in that, The method also includes optimizing the generated SVG file, wherein the optimization methods include: removing identical element rows within the same graphic group, truncating floating-point precision to three decimal places, and removing redundant default attributes.

7. The ODB++ to SVG rendering method according to any one of claims 1-6, characterized in that, The method further includes: The ODB++ to SVG rendering method is encapsulated as an intelligent agent, providing a unified interface to enable large AI models to call the intelligent agent through the unified interface to obtain the SVG file and use it for automated process judgment; the unified interface supports output filtering by production step or by layer.

8. A rendering apparatus for ODB++ to SVG, characterized in that, include: The parsing module is used to parse the ODB++ project directory tree, extract the graph data of the production steps and their nested sub-production steps, as well as the spatial transformation parameters and step repeat array parameters of each production step. The conversion module is used to convert each primitive in ODB++ into an internal object, record the geometric parameters, type identifier and attribute information of each internal object, and map each primitive to the corresponding scalable vector graphics SVG tag; the attribute information includes polarity attribute, layer name, and production step name. The baking module is used to bake the coordinates of each element within a sub-production step to the parent coordinate system through combination transformation based on the spatial transformation parameters of each sub-production step, thereby obtaining the transformed coordinates. A graphics generation module is used to generate reusable graphic blocks based on the SVG tags, transformed coordinates, and rendering colors of each graphic element; wherein the rendering colors are determined based on the polarity attribute of the graphic element. The file generation module is used to call the corresponding reusable graphic block for each instance of the step repeating array in a translational reference manner to generate an SVG file.

9. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement an ODB++ to SVG rendering method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, and the processor executes the computer program to implement an ODB++ to SVG rendering method as described in any one of claims 1-7.

Images