Part History Trees, Parent/Child Relationships, and Regeneration
The benefits that we saw in the Associativity section are derived in large part from the technical underpinnings of "part history trees" and "parent/child relationships". We'll avoid the details of software architecture, but nonetheless attempt to depict how these concepts play a central role in the successful application of solid modeling for production design and manufacturing.
Part History Trees
A "part history tree", as the name would indicate, is a method of defining a 3D object in terms of a tree diagram, wherein "leaves" (the extremities) and "nodes" (the junction of two branches) are used to capture the history and intent of the part's creation process. In simplistic terms, a leaf captures constituent information (see the "rib" and "boss" below) and a node captures how the leaves interact (see "join_rib_boss"). The tree is actually inverted, building first from the branches at the bottom and evolving to the trunk (the final part) at the top.
Parent/Child Relationships
We already see the beginnings of a "parent/child relationship" at the part level... e.g. the "join_rib_boss" is the child of two parents, the "rib" and "boss". But in order to get the cross-part linking depicted in the Associativity section, we need to introduce the concept of parent/child relationships between and amongst parts. As shown below, these parent/child relationships are accomplished by a leaf of a part history tree "pointing" (the red arrows) to the top of another part's history tree.
Parent/Child
Relationships
Notice that unlike within-part history trees, these cross-part relationships can have a child pointing to as few as one parent. In this somewhat simplified context, the "engineering model" part starts with a pointer to its "industrial design" parent and then adds additional elements to its tree (e.g. end plate, rib, boss):
And these parent/child relationships continue upward to include the "mold base", "mold core", and "mold cavity".
Things continue to compound in complexity. Now we want to have "application data" point to some of these underlying parts. This application data doesn't necessarily represent a part but rather data about the part or a particular data set derived from the part.
Examples shown above are:
-
a stress analysis of the mouse rear portion -- including boundary conditions and pressure loading "hung" on the part and the resulting calculated deflection and stress results
-
fixture design for the machine base and clamps -- in this case, one or more parts (with their own history trees) that are dependent on the mold core part
-
NC tool paths -- with machining parameters (e.g. cusp height, stepover, retract plane) that are dependent on the mold core
-
drawings -- with orthographic views, section views (plane and stepped cuts that point to the referenced part), detailed views, and annotation
Regeneration
Regeneration is a software-specific term that means the "beginning-to-end" traversal and recomputation of a part history tree and/or chain of parent/child relationships.
Of greatest meaning (and challenge to the software) is what happens at each node in each part history tree. Most often a "node" represents the cutting, joining, or splitting of material. These cut/join/split operations, or "construction operations", are indeed the heart of any solid modeling system and involve intricate mathematics of "surface intersection" and "topology traversal". When we cut one feature from another, the software first finds the intersection curves between interacting surfaces (more on this in Imported Data), uses these curves to "trim" back the original surfaces, and then sews or "stitches" together the trimmed surfaces to arrive at the resulting object for the node.
Let's view the history tree for the "industrial design" part:
The user can invoke a "regeneration" by simply asking the software to recalculate the part from the existing tree information. In this case, the software re-executes the same steps that it originally did to construct the part (loft, extrude, cut the extrude with the loft, and fillet).
If the user edits some "feature" (leaf or node) of the tree, then the software upon sensing this will regenerate the subject part in order to reflect the underlying edits on the final part. If we edit the loft operation to redefine the sculpted top of the mouse, the "cut" against the "extrude" will be recalculated as will the "fillet" around the outer edge of the mouse.
If we now move our focus all the way to the "mold core" part... the edit that we just made to the "industrial design" part would necessitate a regeneration of its children, in this case the "engineering model"... which would trigger a regeneration of its children, in this case the "mold base"... which would then result in a regeneration of the "mold core" (and also "mold cavity").
Successful regeneration is therefore dependent upon:
-
stability of the "construction operations" within the part -- Are the incoming surfaces "clean" and well-behaved (more in Imported Data)? Can the software calculate the intersections reliably? Can the software trim and re-stitch the surfaces together into a valid part?
-
stable relationships within a "part history tree", i.e. features higher up in the part history tree will often reference (e.g. for positioning, sizing) earlier features -- What happens when a referenced edge or face has been deleted by the edit (or can't be traced from its origins)? Does the feature react in a logical, predictable way? Must the user intervene to define how the feature should react?
-
stable relationships across parts in "parent/child relationships", i.e. now parts higher up in the parent/child chain are dependent upon references to their parents -- What happens when a referenced edge or face has been deleted from the parent (or can't be traced from its origins)? Must the user intervene to define how these interactions should react?
™