A scripted grid and boundary representation dual implementation of three-dimensional modeling method

Abstract

The application discloses a three-dimensional modeling method of a scripted grid and boundary representation dual implementation. Each geometric object respectively maintains its representation attribute, and the representation attribute is a boundary representation attribute or a grid attribute: the geometric object representation attribute carrying a boundary representation entity is the boundary representation attribute, and the geometric object representation attribute not carrying the boundary representation entity is the grid attribute; a geometric operation primitive declares an implementation set when being defined, and the implementation set contains at least one of a grid implementation and a boundary representation implementation; before executing each geometric operation statement, a code execution engine determines, according to an execution mode, the implementation set and a representation attribute of an input geometric object, whether a current execution path is a boundary representation path or a grid path, and the current execution is no longer changed; and the geometric operation statement does not carry a path selection instruction. The application makes the representation of each geometric object independent, switches the automatic selection and at most once execution by the engine, and guarantees the success of mixed modeling by the implementation set.

Description

[0001] This application is related to the following patent applications filed by the applicant on the same day. This application family comprises seven documents, sequentially numbered as Related Application 1 to Related Application 7, corresponding to user file numbers 001 to 007 respectively: "An Automatic Determination and Output Method for Result Shape in 3D Modeling" (User File Number 001), "An Undo and Redo Method for Code-Driven Modeling Based on UI Operations" (User File Number 002), "A 3D Modeling Method Decoupling Code Text and Feature Tree" (User File Number 004), "An AI / UI Collaborative Modeling System with Code Text as the Unique Interface Contract" (User File Number 005), "A Method for Editing Parameter Expressions in 3D Modeling" (User File Number 006), and "A Method for Cross-Kernel and Cross-History Persistence of Topological References in 3D Modeling" (User File Number 007). The user file number for this application is 003. The above applications and this application are based on different technical aspects of the same 3D modeling system, each solving different technical problems and employing different technical means; their protection scopes do not overlap. Technical Field

[0002] This application relates to the field of 3D modeling technology, specifically to a 3D modeling method that provides dual implementation of mesh and boundary representation in a scripting programming language. Background Technology

[0003] 3D modeling systems can be broadly categorized into two types based on geometric representation: boundary representation (B-Rep) and mesh representation. In this application, a boundary representation entity refers to a geometric object maintained by the boundary representation geometric kernel, containing precise surface definitions and entity topological relationships; a mesh entity refers to a discrete geometric object composed of vertices, edges, and triangular faces. Boundary representation can express precise surface and entity topology, but mesh-related operations are difficult to perform on boundary representations, such as implicit surface sampling modeling, knurling and texture vertex displacement, and surface subdivision; complex topological Boolean operations are also prone to failure on boundary representations. The accuracy of mesh representations is limited by the subdivision level, making it impossible to accurately export model files in B-Rep formats such as STEP; face and edge references are unstable after recalculation; and parametric editing and assembly are difficult. In reality, modeling needs often involve multiple operations coexisting in the same scene or even on the same modeling feature chain: first, precisely stretching a flange and then knurling its surface; or importing a precise STEP solid and then using implicit modeling to excavate an internal waterway; or reconstructing a parametric model from a scanned point cloud. A single geometric representation cannot simultaneously meet these needs.

[0004] In scripted modeling and AI-generated code models, geometric operations are performed using statements within the modeling script as the unit of operation. These statements express the modeling intent through function calls, which are executed statement by statement by the code execution engine. This scenario demands a much higher level of determinism in the execution path than interactive modeling: each execution of the same script must follow the same path, the results must be reproducible and cacheable, and the results of other statements must not drift after AI rewrites the parameters of any statement.

[0005] To address the aforementioned issues, existing technologies have proposed several hybrid solutions, but all have shortcomings. The first is a workbench / workflow level separation solution. For example, in FreeCAD, this separates operations into "Part Design Workbench" and "Mesh Workbench," requiring users to manually switch between them and migrate between meshes and solids through manual conversion. This solution relies on manual user operation for path selection, as it doesn't automatically determine the path across different operation surfaces. Hybrid feature chains require repeated manual conversions, making it unsuitable for automated modeling of multiple interleaved operations within a single modeling script chain. The second is a global switch solution, locking a single geometric representation for the entire document or session. This solution cannot be mixed object-by-object: in a scene, some parts require precise export while others require mesh effects; the global switch only allows for one of these two options.

[0006] In addition, there is another type of scheme where the mesh is only used as the triangulation output (preview layer) of the boundary representation kernel. The mesh does not constitute an independent modeling operation: the object type is determined at creation time, and the mesh is just a display appendage of the boundary representation. It is impossible to perform independent modeling operations on the mesh side, nor can it evolve between the two types of operations according to the current representation state of the object.

[0007] In the field of hybrid representation and multi-kernel, existing technologies have developed in three directions, but none of them have fallen into the path of this application: The first type is the fusion of data structures within a single kernel, such as Siemens Parasolid's Convergent Modeling, which extends facet mesh into a new surface type in the boundary representation model, forming a unified convergent body, so that traditional boundary representation operations can be directly applied to the mesh without conversion; in this type of scheme, the mesh facet is embedded in the boundary representation model, the object itself does not distinguish between boundary representation attributes and mesh attributes, there is no representation attribute identity per object, and there is no mechanism for dispatching per statement according to the representation attributes of the input object. The second category is compile-time kernel binding and multi-kernel adaptation mapping. For example, the multi-kernel geometric object and algorithm adaptation mapping method disclosed in Chinese patent document CN122365617A allows developers to select a target kernel from candidate geometric kernels before system compilation or construction. According to the predefined mapping rules corresponding to the kernel, the topological object, geometric object, attribute data, precision data and native algorithm functions are mapped to the platform's unified topological expression and unified algorithm interface. During runtime, the upper-layer application models through the unified interface, and the lower layer calls the kernel bound at compile time. This type of scheme adapts across multiple isomorphic boundary representation kernels and calls a single kernel at runtime. It does not assign between the two types of representations, boundary representation implementation and mesh implementation, nor does it determine the representation attributes of the input geometric object statement by statement at execution time. The third type involves kernels that are externally specified or scheduled based on geometric shape indicators during runtime. For example, the "Geometric Modeling Interface Specification for Multi-Kernel Compatibility" issued by the China Society for Image and Graphics (a group standard of the China Society for Image and Graphics, open for public comment on August 31, 2026, with a comment deadline of September 27, 2026) states that the upper-layer business specifies the target kernel and loads the corresponding adaptation module by the runtime or compile-time management module before executing the modeling task. Another example is some CAD systems where the user selects the default kernel based on features, or schedules kernels among multiple kernels based on geometric shape indicators such as curvature and thickness ratio. The allocation subject of this type of scheme is the upper-layer business, the user, or the shape indicator, and the switching granularity is multiple isomorphic boundary representation kernels. The criterion for judgment is not whether the input geometric object carries a boundary representation entity. Furthermore, some existing technologies switch the modeling backend with a document-level or rendering-level global switch (such as OpenSCAD's preview and rendering dual modes), without operational-level judgment and without per-object state; implicit modeling tools, point cloud reverse engineering tools, and parametric modeling tools in existing technologies are usually independent workflows, with data transferred between tools in the form of files, lacking a solution that uses a unified dispatch mechanism to carry multiple modeling methods such as boundary representation, mesh, implicit and point cloud reverse engineering in the same modeling script.

[0008] In scenarios where AI generates modeling code, the aforementioned path determination methods completely fail: AI struggles to predict runtime failures during code generation, cannot manually switch paths for the user, and cannot determine the kernel at compile time. If path branches or runtime fallbacks are explicitly written in the generated code (e.g., switching to a mesh path after a failure), the path selection logic becomes completely disconnected from the modeling intent. Figure 1 The presence of these elements within the code content leads to results drifting with runtime conditions, complex caching implementations, and high code coupling. This application takes the opposite approach: scripting and AI-generated code modeling requires decoupling of path determination from statement content—AI is only responsible for expressing the modeling intent (which geometric operation statements to write), and the code content does not carry any path selection instructions. The path taken by each geometric operation statement is determined by the code execution engine according to fixed rules before execution, and this determination remains unchanged during the current execution. Furthermore, the path is redefined before each statement is executed, eliminating the need to write path branches or fallbacks in the code.

[0009] Therefore, existing technologies lack an execution mechanism that can carry multiple types of modeling operations on the same operating surface, with a single execution chain, determine the path before execution, maintain the representation attributes of each geometric object, deterministically reduce and notify the functional modules when attributes are switched, switch at most once and be guaranteed to succeed by the implementation set, and have predictable and reproducible behavior. Summary of the Invention

[0010] The technical problem this application aims to solve is: how to ensure that boundary representation modeling, mesh modeling, implicit modeling, and point cloud inverse modeling are executed in a unified and interleaved manner on the same modeling chain in 3D modeling using scripting and AI-generated code, and how to decouple the execution path determination of each geometric operation statement from the statement content, so that the code execution engine assigns the execution path according to fixed rules before each statement is executed at runtime, thus ensuring that the behavior is deterministic and reproducible.

[0011] To address the aforementioned technical problems, this application provides a 3D modeling method that combines scripted meshing and boundary representation. In this application, geometric operations are implemented using statements within the modeling script. Geometric operation primitives, as referred to in this application, are geometric functions defined in libraries (standard or third-party libraries) and callable from modeling scripts. They are the smallest callable units expressing modeling intent, such as creation, transformation, Boolean operations, beveling, implicit sampling, and loading. Each geometric operation primitive declares its implementation set in its definition. Geometric operations, as referred to in this application, are operations that call geometric operation primitives and generate geometric objects. Geometric operation statements, as referred to in this application, are statements in the modeling script that call geometric operation primitives. These statements reference the called geometric operation primitives in the form of function calls and carry actual parameters (e.g., "let b = union(a, c)"), and are executed line by line by the code execution engine. The division of labor among primitives, operations, and statements is as follows: the declaration of the implementation set occurs in the definition of the geometric operation primitive (library side); the determination of the execution path occurs before statement execution (engine side); and script statements only express which geometric operation primitive is called and with what parameters, without declaring the implementation set. Therefore, the "geometric operation" of this application differs from existing systems that use user interface menus or geometric kernel calls as operation units: the operation content is determined by script statements, and the operation path is determined by the code execution engine according to fixed rules.

[0012] The determination of the above execution path occurs within the code execution engine; the mechanism by which the code execution engine executes the modeling script at the statement level falls within the scope of the execution engine of related application 5, "An AI / UI Collaborative Modeling System with Code Text as the Unique Interface Contract". This application does not advocate execution granularity; the code execution engine behavior advocated in this application is limited to determining the execution path and completing the switching of representation attributes based on the execution mode, implementation set and representation attributes.

[0013] This application maintains a single execution chain for the modeling script: the execution chain is composed of geometric operation statements and the input / output geometric objects of the geometric operation statements according to their dependencies. Multi-part modeling is achieved by the operation branches of each part forming the same execution chain. Each geometric object on the execution chain has a representation attribute, which is either a boundary representation attribute or a mesh attribute: when a geometric object carries a boundary representation entity, the representation attribute is a boundary representation attribute; when it does not carry a boundary representation entity, the representation attribute is a mesh attribute. There is no global representation attribute flag, and the representation attributes of each geometric object do not affect each other. For a single geometric object, its operation history constitutes a branch chain on the execution chain, and the representation attribute is continuous along this branch chain: before the switch occurs, the representation attribute of the object is always a boundary representation attribute; after the switch occurs, it is always a mesh attribute, and there is no back-and-forth jump; the representation attribute undergoes at most one switch from boundary representation attribute to mesh attribute (switching point), and the boundary representation is not restored after the switch. The entire execution chain is a hybrid chain: the representation attributes of different geometric objects on the chain can be different, and the representation attributes of the same geometric object can be different before and after the switching point, but the switch occurs at most once.

[0014] The implementation set is declared in the definition of the geometric operation primitive. This implementation set includes the existence of mesh implementations and boundary representation implementations, and must contain at least one implementation. The implementation set is fixed in the definition of the geometric operation primitive. Geometric operation statements in the script do not declare implementation sets. When responding to a geometric operation statement, before executing the statement, the execution path is determined as either a boundary representation path or a mesh path based on the execution mode, the implementation set of the geometric operation primitive called by the statement, and the representation attributes of the input geometric object. This determination remains unchanged during the current execution. Before executing each geometric operation statement, the path is re-determined based on the execution mode, the implementation set of the geometric operation primitive called by the statement, and the representation attributes of the input geometric object. Finally, the corresponding implementation execution statement is called according to the determined path, and the geometric object is output: the boundary representation path calls the boundary representation implementation, producing a geometric object carrying a boundary representation entity and having the boundary representation attribute; the mesh path calls the mesh implementation, producing a geometric object with the mesh attribute. When the execution of a geometry operation statement causes the representation attribute of the input geometry object to switch from a boundary representation attribute to a mesh attribute (this switching only occurs in automatic mode), mesh reduction is performed only on input geometry objects whose representation attribute is a boundary representation attribute, and the representation attribute of that geometry object is switched to a mesh attribute; this switching is a normalization of the input data rather than an error rollback. Success of the switching is guaranteed by the implementation set: the implementation set of each geometry operation primitive contains at least one implementation, and the implementation set consists only of mesh implementations and boundary representation implementations; in automatic mode, when a statement needs to switch to a mesh path (its calling geometry operation primitive only declares a mesh implementation, or the representation attribute of the input geometry object is a mesh attribute), the geometry operation primitive has declared a mesh implementation, and the mesh path has a callable implementation, so the switching will not fail due to a lack of implementations.

[0015] Modeling scripts are generated by artificial intelligence (AI), user interface (UI) operations, or a combination of both: AI generates a sequence of geometric operation statements as needed, the UI translates interactive operations into geometric operation statements, and both are written into the same codebase and executed by the same code execution engine. The chain is driven by AI and the UI—they determine which geometric operation statements are included in the script; the chain's direction is fixed in the pre-execution dispatch rules of the code execution engine—whether each statement follows a boundary representation path or a mesh path is determined before execution based on the execution mode, the implementation set of the geometric operation primitives called by the statement, the representation attributes of the input geometric object, and the required capabilities. This determination remains unchanged during the current execution, but is redefined before each statement's execution. AI-generated script statements do not carry path selection instructions and cannot have their fixed direction rules altered by rewriting statements; after AI rewrites any statement, the path determination rules remain constant, and the representation attributes are redefined based on the rewritten statement.

[0016] In one implementation, the execution modes include automatic mode, boundary representation forced mode, and mesh forced mode. In automatic mode, the boundary representation path is prioritized; if the boundary representation implementation is missing, the representation attribute of the input geometry is a mesh attribute, or the required capability is missing, the mesh path is used instead. In boundary representation forced mode, unsupported cases are explicitly reported and do not automatically switch. In mesh forced mode, all operations follow the mesh path. Thus, the path is determined before execution and does not change during execution, making the results reproducible.

[0017] In one implementation, each geometric object has its own representation attribute: the representation attribute of a geometric object is uniquely determined by whether the object carries a boundary representation entity, there is no global representation attribute flag, and the representation attributes of each geometric object do not affect each other. Therefore, if an object switches to a mesh attribute due to a mesh-type operation, it does not affect other objects in the same execution chain from continuing to follow the boundary representation path. Hybrid scenarios are naturally established without the need for any global switches.

[0018] In one implementation, the implementation set is provided declaratively: geometric operation primitives declare the existence of mesh and boundary representation implementations through declarative interfaces at definition time, and the code execution engine uniformly dispatches them, without the implementer writing dispatch logic; the implementation set includes three categories: mesh-only implementations, boundary representation-only implementations, and both. Thus, library authors only declare the implementation set, and the dispatch rules are maintained at a single point in the code execution engine, eliminating the need for fragmented judgments by third-party libraries.

[0019] In one implementation, the geometric operation primitive declares the required capabilities in its definition, which refer to the geometric operation capabilities supported by the boundary representation implementation, including at least one of surface evolution, repair, direct editing, advanced surfaces, and assembly; the code execution engine queries the set of capabilities implemented by the boundary representation before dispatching, and if the required capability is missing, the automatic mode changes to the mesh path, while the boundary representation forced mode reports an error and does not forge the missing capability.

[0020] In one implementation, when the execution mode is automatic, the switching occurs when: the geometric operation primitive called by the statement only declares a mesh implementation, and the input geometry contains objects whose representation attribute is a mesh attribute; at the time of switching, mesh reduction (at least one of vertex welding, deleting degenerate faces, unifying orientation, and manifold assertion) is performed only on the input geometry objects whose representation attribute is a boundary representation attribute, and the input geometry objects whose representation attribute is a mesh attribute are passed through as is; the switch is permanent, and the boundary representation is not restored. In the boundary representation forced mode, the above situations explicitly report an error, and no switching occurs; in the mesh forced mode, all operations follow the mesh path from the beginning, and there is no switching. Thus, the switching is a normalization of the input data rather than an error rollback, and the behavior of the full boundary representation or full mesh scene remains unchanged.

[0021] In one implementation, when a geometric operation statement has geometric input, all input geometric objects have boundary representation attributes, and the output geometric object has mesh attributes, the code execution engine uniformly issues an event notification. The notification includes the object identifier, the caller, and the switching reason, enabling the functional module to detect the loss of precision and respond.

[0022] In one implementation, the representation attributes of a geometric object are determined during creation or loading: when a creation statement is executed with empty input and the called geometric operation primitive declares a boundary representation implementation, the representation attribute is automatically determined to be a boundary representation attribute; the loading statement determines the representation attribute according to the source data format. When the source data format is B-Rep (STEP / STP, etc.), the representation attribute is a boundary representation attribute; when the source data format is Mesh (STL / OBJ / 3MF, etc.) or point cloud (PLY / XYZ / LAS, etc.), the representation attribute is a mesh attribute. In mesh-forced mode, the loading statement follows the mesh path, and the output is a mesh attribute; the determination is based on format hints or the source data file name extension, with format hints taking precedence over extensions. Therefore, the import path is also determined before execution, consistent with the operation path determination.

[0023] In one implementation, implicit modeling defines geometry using a signed distance function and generates a mesh by sampling the geometry. Implicit modeling primitives declare the mesh implementation, and the output represents the mesh attributes. Thus, implicit modeling, as a generative geometric operation on the mesh side, is uniformly integrated into the execution chain.

[0024] In one implementation, during point cloud reverse modeling, the point cloud format is determined as a mesh attribute by a loading statement. Denoising, registration, and mesh reconstruction are completed on the mesh side, and the product represents the mesh attribute. Subsequent operations are performed along the mesh path.

[0025] In one implementation, the display data for a geometric object representing a boundary representation attribute is derived from the boundary representation entity carried by that geometric object itself, and the derivation of the display data is independent of geometric objects representing a mesh attribute. Thus, the boundary representation side and the mesh side each display according to their respective representation capabilities, and the mesh side does not assume the auxiliary function of displaying the boundary representation.

[0026] In one implementation, the Boolean and transformation operations performed on the boundary representation path record the surface evolution mapping from the input surface to the output surface. The surface evolution mapping is maintained per-object by geometry object and is used for stability verification of surface references and surface migration.

[0027] In one implementation, a geometric object whose attribute is a boundary representation attribute carries a local coordinate system offset. When a geometric operation statement is executed in the world coordinate system, the world coordinates are converted to local coordinates by the offset before the operation is executed, ensuring that the operation is executed in the correct coordinate system before the switch.

[0028] This application differs from existing technologies in at least the following ways: Compared to the first type of kernel-in-kernel fusion scheme (e.g., Convergent Modeling), this application does not embed the mesh as a face type of the boundary representation model. Instead, it retains two independent implementations: the boundary representation implementation and the mesh implementation. Each geometric object explicitly registers its representation attributes in its identity slot, and the code execution engine assigns it to the corresponding implementation based on these attributes. Compared to the second type of compile-time kernel binding scheme (e.g., CN122365617A), this application does not have the developer fixate on a single geometric kernel during compilation or build. Instead, before each geometric operation statement is executed, the code execution engine determines the boundary representation path and mesh path statement by statement based on the execution mode, the implementation set of the geometric operation primitives called by the statement, and the representation attributes of the input geometric object. This determination remains unchanged during the current execution. Compared to the third type of runtime... Compared to externally specified or shape index scheduling schemes, the dispatching entity in this application is the code execution engine, not the upper-layer business or user. The determination criterion is whether the input geometric object carries a boundary representation entity, rather than user selection or shape indices such as curvature and thickness ratio. Compared to document-level or rendering-level global switch schemes, the representation attributes in this application are maintained on an object-by-object basis, and different objects on the same execution chain can be in different representation attributes. In addition, the representation attribute of a single geometric object will switch from the boundary representation attribute to the mesh attribute at most once, and will not be restored after the switch. The geometric operation statement does not carry path selection instructions, the path determination is decoupled from the statement content, the execution path is determined before execution and remains unchanged during execution, the result is definite and reproducible, and the path determination rule remains constant after rewriting any statement.

[0029] Beneficial effects: First, a single script chain can simultaneously carry precise boundary representation operations and mesh operations, allowing hybrid modeling needs to be completed on the same operational surface; Second, object-by-object attribute representation allocates accuracy and performance to objects, eliminating the need for global switches; Third, pre-determining the path ensures deterministic and reproducible results, and the rules remain constant after AI rewriting; Fourth, deterministic reduction and notification of functional modules at the time of switching make accuracy loss explicitly controllable; Fifth, switching is at most once and permanent, avoiding repeated conversions; Sixth, implementing set declarations and capability routing ensures that adding new implementations does not affect the dispatch rules of existing statements; Seventh, the same script can be executed on different geometric implementations, with the path determined by the capabilities of each implementation. Attached Figure Description

[0030] 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 of this application or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0031] Figure 1A schematic diagram of the system structure of a 3D modeling method that combines scripted mesh and boundary representation, provided in an embodiment of this application; Figure 2 A flowchart illustrating a scripted mesh and boundary representation dual-implementation 3D modeling method provided in this application embodiment; Figure 3 This is a flowchart illustrating the determination and switching of geometric object representation attributes, provided in an embodiment of this application. Detailed Implementation

[0032] 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, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0033] The following description of some technologies involved in the embodiments of this application is provided to aid understanding and should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, some descriptions of well-known functions and structures are omitted in the following description.

[0034] Figure 1 The system architecture of the method of this application is shown, including a code storage module, an implementation set declaration, a code execution engine, a representation attribute maintenance module, and a single execution chain; Figure 2 This paper illustrates the overall flow of the method described in this application. Geometric operation statements in the modeling script call geometric operation primitives with implementation sets. After pre-execution dispatch, they are merged into a single execution chain according to the determined boundary representation path or mesh path. The code execution engine referred to in this application is an engine that executes the modeling script line by line, maintains the representation attributes of geometric objects, and determines the execution path before executing each statement. The code execution engine runs within the modeling system, and its interface with other modules of the modeling system is detailed in related application five of this application family. When the code execution engine in related application five executes geometric operation statements or calls geometric operation primitives in the script, a dual-path execution unit located within the code execution engine determines the geometric path before execution. The external responsibilities of this dual-path execution unit have been described in related application five, and its internal mechanism is elaborated in this application. Figure 1The pre-execution dispatch module and representation attribute maintenance module, shown, constitute the internal components of this dual-path execution unit: Before the geometric implementation of each statement runs, the pre-execution dispatch module determines the execution path based on the execution mode, the implementation set of the geometric operation primitives called by the statement, and the representation attributes of the input geometric object; the representation attribute maintenance module maintains the representation attribute identity slot for each geometric object during runtime and performs directional reduction when switching from boundary representation attributes to mesh attributes. The geometric operation statements in the modeling script express the modeling intent in the form of function calls and are executed line by line by the code execution engine.

[0035] Geometric operation primitives in the library define their implementation sets through declarative interfaces. Primitive authors only declare the existence of mesh and boundary representation implementations, without writing any path dispatch logic. Geometric operation statements in scripts simply call the defined geometric operation primitives without declaring their implementation sets. The following are the definition forms of three typical geometric operation primitives in the standard library: Simultaneously declare the geometric operation primitives (Boolean union) for both mesh implementation and boundary representation implementation: union = defineOp({ mesh: (...shapes) => Mesh Boolean(Oriented Reduction(shapes)), brep: (...shapes) => Boundary representation (shapes) capabilities: ['Surface Evolution'], }) Geometric operation primitives implemented only for boundary representation (beveling): chamfer = defineOp({ brep: (input, params) => Boundary indicates chamfer (input, params). }) Geometric operation primitives implemented only in meshes (implicit modeling): sdf = defineOp({ mesh: async (params) => mesh sampling (params), }) Definition-time verification: At least one mesh implementation and one boundary representation implementation must be provided; otherwise, registration is rejected. Geometric inputs are automatically identified by the parameter list during execution (determined by object identity), and the author does not need to specify which parameters are geometric inputs. The geometric operation primitives referred to in this application are geometric functions defined in the library and callable in the modeling script, whose definitions declare implementation sets. The geometric operation referred to in this application is the operation that calls the geometric operation primitive and generates a geometric object. The geometric operation statement referred to in this application is the statement in the modeling script that calls the geometric operation primitive; the statement references the geometric operation primitive in the form of a function call and carries actual parameters. The geometric operation primitive declares its implementation set in its definition, while the geometric operation statement itself does not declare an implementation set. The path selection instruction referred to in this application is the statement component in the modeling script used to specify the geometric path to be taken in this execution, including path branch statements, path selection parameters, and fallback logic for taking another path after execution failure. The geometric operation statements in this application do not carry path selection instructions; the execution path of each statement is determined by the code execution engine before execution.

[0036] Per-object maintenance of attributes: Each geometric object holds an identity slot at runtime. The product of a boundary representation path is constructed using the constructor `fromBrep(mesh data, {boundary representation handle})`, registering the handle in the object's identity slot during construction; the product of a mesh path is constructed using the constructor `solid(mesh data)`, registering only the object identity, not the handle. Therefore, for any geometric object: Whether to carry a boundary representation entity = (whether a boundary representation handle is registered in the object's identity slot) If the condition is true, the object's representation attribute is a boundary representation attribute; otherwise, it is a mesh attribute. Representation attributes are entirely determined by the object's own identity slot; there is no global representation attribute flag. The display data of a boundary representation attribute object is derived from the triangulation of its carried boundary representation entity and is unrelated to mesh attribute objects; the display of a mesh attribute object is its mesh data.

[0037] Before each statement is executed and before the implementation has run, the code execution engine calls the dispatch function (input array, implementation set, required capabilities) to determine the current execution path based on the execution mode. Once determined, the path remains unchanged. Mesh Forced Mode: Always follow the mesh path; if no mesh is implemented, an error will occur. Boundary representation forced mode: Explicitly report an error when there is no boundary representation implementation, the input does not fully carry boundary representation handles, or the current engine lacks the required capabilities; Automatic mode (default): Step 1, capability routing - if the required capability is missing in the current engine capability table, if there is a mesh implementation, the mesh path will be used; otherwise, an error will be reported. Step 2, if the boundary representation implementation exists and all inputs carry boundary representation handles, the boundary representation path will be used. Step 3, otherwise, if there is a mesh implementation, the mesh path will be used; otherwise, an error will be reported.

[0038] Dispatch is completed before execution, and during execution, the path is not changed due to exceptions. Exceptions are reported accurately and the statement is located. When a class creation statement is executed with empty input and the geometric operation primitives called are declared with bounded representations, the empty input satisfies the "all carry boundary representation handles" criterion, and the boundary representation attribute object is automatically generated.

[0039] Directional reduction and event notification during switching: When mixed inputs (both with and without handles) or geometric operation primitives that only declare mesh implementations receive boundary representation inputs, they are dispatched as mesh paths in automatic mode. The mesh path entry performs directional reduction on the input array: for inputs without handles, it returns directly; for inputs with handles, only the inputs with handles are subjected to mesh reduction (vertex welding, degenerate face removal, uniform orientation, manifold assertion), while other mesh inputs are passed through as is. After reduction, the handles in the identity slot of the input object are no longer valid, and its representation attribute is switched to the mesh attribute.

[0040] When a statement has geometric input, all input representation attributes are boundary representation attributes, and the output representation attribute is a mesh attribute, the code execution engine issues a switching event. The event carries the object identifier, the caller, and the switching reason. The functional module responds accordingly, for example, marking the corresponding object as a triangulated exported object. The switch is permanent: the representation attribute of a single object will switch from boundary representation attribute to mesh attribute at most once. In automatic mode, when a mesh path needs to be followed, the geometric operation primitives called by the statement have already declared mesh implementations (the implementation set is non-empty and contains only mesh and boundary representation attributes), so the switching success can be guaranteed by the implementation set.

[0041] Indicates the initial determination of the attribute: Figure 3This demonstrates the process for determining and switching representation attributes. When a creation statement is executed with empty input and the called geometric operation primitive declares a boundary representation implementation, it is automatically determined to be a boundary representation attribute. Loading statements are determined based on the source data format: when the source data format is B-Rep (STEP, STP, etc.), it imports a boundary representation entity and is determined to be a boundary representation attribute; when the source data format is Mesh (STL, OBJ, 3MF, etc.) or point cloud (PLY, XYZ, LAS, etc.), it is determined to be a mesh attribute. In mesh-forced mode, loading statements follow the mesh path, and the output is a mesh attribute. Determination is based on format hints or the source data file name extension, with format hints taking precedence over extensions. Implicit modeling primitives declare mesh implementations, and the sampled output represents mesh attributes.

[0042] In a specific example, the process of switching representation attributes on a single execution chain is as follows. Assume there is a part `brepPart` in the execution chain, whose representation attribute is a boundary representation attribute. The `split` statement is executed to obtain two sub-objects, `partA` and `partB`, both initially representing the boundary representation attribute. Then, a Boolean operation is performed on `partA` and an implicit modeling result: the implicit modeling result is generated by sampling using a signed distance function, its primitive declares a mesh implementation, and its representation attribute is a mesh attribute; due to the mixed input (`partA` is a boundary representation attribute, and the implicit modeling result is a mesh attribute), the Boolean statement determines the mesh path before execution. After orientation and reduction of `partA`, its representation attribute switches to a mesh attribute, and the Boolean result is a mesh attribute. `partA` and the implicit modeling result complete the Boolean operation on the same mesh path. Simultaneously, the `chamfer` statement is executed on `partB`: the chamfer primitive only declares a boundary representation implementation and relies on direct editing capabilities; `partB` is a boundary representation attribute. The chamfer statement determines the boundary representation path before execution, and the result is still a boundary representation attribute. Thus, the two branches of the same execution chain evolve independently: partA carries mesh Boolean after a switch, while partB carries precise chamfering, and the two branches do not contaminate each other.

[0043] The boundary representation path records the Boolean and transformation operations on the input surface to the output surface, mapping the surface evolution. This mapping is maintained per object of geometry and used for surface reference stability verification and surface migration (this mapping is the factual basis for the seven-topology naming of associated applications). Objects with boundary representation attributes carry local coordinate system offsets, which are converted when statements are executed in the world coordinate system. When a function is used as the execution unit, the handle registration domain is opened upon entering the function body, and newly created handles are released after the function returns, except for handles reachable by the return value.

[0044] Boundary representation implementation and mesh implementation are connected via adapters: the code execution engine defines a unified implementation interface and requires the adapter to declare a set of capabilities. The dispatch rules are decoupled from the specific kernel. Adding a new geometry kernel only requires implementing the interface and declaring capabilities.

Claims

1. A 3D modeling method that combines scripted mesh and boundary representation, wherein the modeling script is executed by a code execution engine, characterized in that, include: The code execution engine maintains a representation attribute for each geometric object in the modeling script. The representation attribute is either a boundary representation attribute or a mesh attribute. When a geometric object carries a boundary representation entity, the representation attribute is a boundary representation attribute; when it does not carry a boundary representation entity, the representation attribute is a mesh attribute. The modeling script includes geometric operation statements, which are statements in the script that call geometric operation primitives. The geometric operation primitives are geometric functions defined in the library that can be called by script statements. Each geometric operation primitive declares an implementation set in its definition. The implementation set includes at least one of the mesh implementation and boundary representation implementation supported by the primitive. The geometric operation statements do not declare an implementation set. Before executing each geometric operation statement, the code execution engine determines whether the current execution path is a boundary representation path or a mesh path based on the execution mode, the implementation set of the geometric operation primitives called by the statement, and the representation attributes of the geometric object input by the statement. The execution mode is a configuration parameter that indicates the priority and mandatory relationship between the boundary representation path and the mesh path. The execution path does not change during the current execution. The corresponding implementation is called according to the execution path to execute the statement and output the geometry object. The output geometry object of the boundary representation path carries the boundary representation entity, while the output geometry object of the mesh path does not carry the boundary representation entity. When an execution causes the representation attribute of an input geometry object to switch from a boundary representation attribute to a mesh attribute, the representation attribute of a single geometry object undergoes the switch at most once. The geometry operation primitives called by the geometry operation statement that is determined to follow the mesh path and causes the input representation attribute switch have a set of implementations that include mesh implementations, and the switch does not fail due to a lack of implementations. The geometric operation statements do not carry path selection instructions, and the determination of the execution path is completed by the code execution engine.

2. The method according to claim 1, characterized in that, The execution modes include automatic mode, boundary representation forced mode, and mesh forced mode: In automatic mode, the boundary representation path is prioritized, and if the boundary representation implementation is missing, the representation attribute of the input geometry object is a mesh attribute, or the required capability is missing, the mesh path is used instead; In boundary representation forced mode, errors are reported for unsupported cases and the mode does not switch automatically; In mesh forced mode, all geometry operation statements follow the mesh path.

3. The method according to claim 1, characterized in that, The representation attributes are maintained separately for each geometric object by the code execution engine: the representation attributes of a geometric object are uniquely determined by whether the geometric object carries a boundary representation entity, there is no global representation attribute flag, and the representation attributes of each geometric object do not affect each other; whether or not a boundary representation entity is carried is reflected in whether a boundary representation handle is registered in the identity slot of the geometric object.

4. The method according to claim 1, characterized in that, The implementation set is provided in a declarative manner. When the geometric operation primitives are defined, the existence of mesh implementation and boundary representation implementation is declared through a declarative interface. The code execution engine uniformly dispatches the implementations, and the implementer does not need to write the dispatch logic. The implementation set includes three types: mesh-only implementation, boundary representation-only implementation, and implementations of both mesh and boundary representation.

5. The method according to claim 2, characterized in that, When the execution mode is automatic, if the execution path is a mesh path and there are geometric objects in the input geometry that have a boundary representation attribute, mesh reduction is only performed on the input geometry objects that have a boundary representation attribute. Input geometry objects that have a mesh attribute are passed through as is. After reduction, the representation attribute of the input geometry object is switched to the mesh attribute. The mesh reduction includes at least one of vertex welding, deleting degenerate faces, unifying orientation, and manifold assertion.

6. The method according to claim 1, characterized in that, When a geometric operation statement has geometric input, all input geometric objects have boundary representation attributes, and the output geometric object has mesh representation attributes, the code execution engine will issue a unified event notification. The event notification includes the object identifier, the caller, and the switching reason.

7. The method according to claim 1, characterized in that, The representation attributes of a geometric object are determined at creation or loading time: when the creation statement is executed with empty input and the geometric operation primitives called by the statement are declared to have boundary representations, the representation attribute is automatically determined to be a boundary representation attribute. The loading statement determines the representation attribute according to the source data format. When the source data format is B-Rep, the representation attribute is the boundary representation attribute. When the source data format is Mesh, the representation attribute is the mesh attribute. In mesh forced mode, the loading statement follows the mesh path and the product is the mesh attribute. The determination is based on either the format hint or the source data file name extension, with the format hint taking precedence over the extension.

8. The method according to claim 1, characterized in that, The method also includes implicit modeling: defining geometry through a signed distance function and sampling the geometry to generate a mesh, wherein the implicit modeling primitive declares the mesh implementation, and the generated geometric objects are represented by mesh attributes.

9. The method according to claim 1, characterized in that, The display data of a geometric object whose attribute is a boundary representation attribute is derived from the boundary representation entity carried by the geometric object itself, and the derivation of the display data is independent of the geometric object whose attribute is a mesh attribute.

10. The method according to claim 1, characterized in that, The rules for determining the execution path remain unchanged after rewriting the parameters of any geometric operation statement in the modeling script.

Images