JointSearch: Efficient parametric detailing preparation through user-defined and property-based joint type filtering

Introduction

An important aspect of designing structures is to detail the joints – the intersection of building elements. The detailing of a joint is dependent on a series of constraints, including architectural, structural and manufacturing constraints. ¹

Digital fabrication and algorithmic aided design (AAD) have evolved and will continue to evolve the building industry (BI): Digital fabrication and computer numerical control (CNC) machines expand the domains of rational manufacturing. Not dependent on jigs and manual labour, CNC machines are universal ² and can produce variations at no extra cost. ³ This mode of production is referred to as nonstandard seriality ⁴ and substantiates a mass-customised BI. ⁵ Similarly, AAD is crucial for expanding what is rational to digitally design. The digital aspect of nonstandard seriality is achieved by building algorithms that generate geometry based on custom inputs.

In parallel, visual programming software, such as Grasshopper3D ⁶ and Dynamo Studio, ⁷ has democratised algorithmic modelling and enables designers with limited programming knowledge to utilise the power of both parametric modelling and digital fabrication. Arguably, digital tools have changed the conceptions and requirements of a detail. ⁸

Regardless of the AAD, the logic that separates a set of joints into joint types varies from project to project. The previously mentioned joint types in La Seine Musicale were constrained by the beam types connected in the joint (two diagonals, a diagonal and a horizontal beam (referred to as ring)). ⁹ Similarly, a beam that is connected to a column is likely to be detailed differently than a secondary beam that is connected to a primary beam. Thus, these two cases belong to two joint types. In other cases, other geometric parameters are determinant.

An important task of preparing a parametric detailing is to define a logic that defines elements, generates all preliminary joint relations, assigns all joints to their joint type parametric system and outputs a joint’s geometric data stream in the most possible coherent manner (refer to Figure 1). The purpose of this task is to prepare sufficient input data for each joint type’s parametric detailing system.

OPEN IN VIEWER

Figure 1.

Four steps for preparing a parametric detailing.

CITA has developed solutions for creating and storing information to generate joints.^11,12 Similarly, but more universal, Wassim Jabi and Robert Aish are developing Topologic, which is a kit for non-manifold topologies (NTMs). ¹³ This toolkit is open-source and allows the user to build topologic relations that combines vertices, lines, wires, faces, shells and cells.

If a structure is logically clear, a small sorting algorithm may be used to filter the joint types. However, the algorithm is likely to be dependent on a fixed topology. Complex structures require other methods, and in the case of La Seine Musicale, a spreadsheet interface was employed to assign the correct type to each joint. ⁹ A different strategy is to write a custom algorithm that filters joints based on defined properties – Buro Happold identified similar connections in the Morpheus Hotel exoskeleton by applying this strategy. ¹⁴ Rhino.Inside for Revit enables the user to filter geometry using predefined geometric rules. ¹⁵ Front Inc. has developed a toolkit named Elefront, which enables the user to filter geometry based on custom key-values that are assigned to a geometry. ¹⁶

As introduced above, methods for assigning joints to joint types exist. However, these methods of identifying joints are dependent on a fixed and distinct global topology or require advanced parametric thinking. The result is a fragile parametric model or a time-demanding process of preparing a model for detailing.

In all types of detailing, properties and detailing-specific constraints define a joint type’s solution space. Thus, a tool that enables the user to intuitively transfer these properties and constraints to an algorithm is needed.

This article presents a methodology that efficiently generates topological relations and enables the user to assign joint instances to joint types. A series of property-based search criteria components is used to define the solution space of a joint type. Valid joints are coherently filtered, deconstructed and outputted and customised for detailing. The result is a universal method that turns joint type identification independent from its global topology.

The tools are prototyped in a Grasshopper toolkit named Reindeer. The toolkit is under development and customised for detailing fabrication-ready timber structures. Other articles explain the overall framework ⁵ and timber-specific tools. ¹⁷

This article explains the methodology and programming-related aspects of the developed tools. Brief examples and a built case structure demonstrate and evaluate the tool. A brief conclusion is provided.

Proposed methodology

As most projects invent a new joint type variation, the number of possible joint types is almost infinite. Therefore, predefining all joint type solution spaces is not possible. Rather, the designer should be free to define and update a joint type’s solution space while designing. This chapter proposes such a methodology. To explain the principle, a BottomChord joint type in a timber truss bridge is employed. See Figure 2.

OPEN IN VIEWER

Figure 2.

The timber truss bridge and the BottomChord joint type’s solution space.

Any joint type has an intended purpose, such as structurally connecting two bars, a chord and a secondary beam. Thus, only valid joints must be detailed according to their joint type.

A well parametrically detailed joint enables some flexibility in its solution space ⁹ and is likely to have some threshold values that cause the joint to belong to another joint type. In this context, a solution space is an arbitrary space that capsules all possible variations of a joint type. If a joint instance is inside the joint type’s solution space, it belongs to this joint type. The BottomChord joint type has the following property criteria that define the solution space. Note that the following property criteria correspond to both the joint and its elements.

If a joint fails one of the property criteria, it does not belong to the BottomChord joint type. For example, if the BottomChord is not continuous, the joint is located at the end of the bridge. In this case, these joints must be defined as another joint type. ¹⁸ Some properties allow a domain of allowed values, while other properties are Boolean. In the example, the combination of elements is fixed, while the angle between the bars and the chord allows a variation. In theory, all thinkable parameters are definable in a joint type. But if no joint instances are close to exceeding the threshold value, there is no practical function for defining it. In the example, the length of each bar is a redundant solution space parameter to define. A joint type’s solution space can be visualised using parallel coordinates. Figure 3 shows one property for each column and the size of the allowed domain. The figure compares Joint0 and Joint1 against the BottomChord joint solution space. Joint1 is valid, and Joint0 is invalid.

OPEN IN VIEWER

Figure 3.

BottomChord joint type’s solution space visualised in parallel coordinates. Joint0 and Joint1 tested if belong to BottomChord joint type. Joint0 fails the test.

The outcome of defining a joint type solution space in this way is dual. Primarily, correct joints are assigned to correct joint types. However, a second application can be equally relevant. If assigned joints are visualised in real time, the designer can adjust the geometry until all joints belong to a detailed joint type. In this way, the method can also be applied for optimisation purposes.

This example showed how a BottomChord joint type’s solution space was defined. However, this method should work for all types of joints, regardless of material or function. To generalise the method, the solution space is modularised. Each module equals a property, and each property should have an adjustable domain. In this way, the user can easily add the properties that are relevant for defining a specific solution space. In some cases, one property is sufficient; for other joints, multiple properties are needed. Figure 4 shows how two sets of property criteria can filter two bridges and three shells.

OPEN IN VIEWER

Figure 4.

Modularisation of property criteria. Two bridges and three shells are analysed to find two types of joints.

This methodology is likely to be applicable for NTMs ¹³ and can be used to filter any kind of joint. A joint can be point based, edge based or even face based. The only requirements are that the defining solution space must cover both the object and its neighbours and the structure’s elements must have sufficient property information for evaluation. By example, a joint type search can be performed in a cross-laminated timber structure. If the plates are idealised as faces, and the faces are attributed with properties such as name and width, the same solution space method can be employed. The methodology is expected to work universally, regardless of industry, material or topology.

Implementation

To test the proposed methodology, a prototype is developed and implemented as a plugin for Grasshopper3D. To limit the scope, one-dimensional (1D) timber elements and seven property criteria were determined to be sufficient for implementation.

The following workflow is adapted to timber structures and are the steps used when applying Reindeer. Timber-specific content, such as material, cross-sections, detailing principles and manufacturing technology, can be placeholders for other materials.

Step 4a is a prototype of the described methodology. To ensure that this step works and has a practical purpose, steps 1–3 and 4b are equally important. These four steps are chronologically presented in the next section.

Defining joints

In Reindeer, a joint consists of a node and its 1D element(s). ¹⁷ Nodes are not specified by the user, but a result of elements that intersect. ⁹ From the structural analysis perspective, elements can only intersect at the ends of a 1D element. From a detailing perspective, however, one element can meet another element in the middle. ⁵ The bridge example illustrates this concept. Thus, two events generate a node:

The starting point or endpoint of an element

Elements intersect within the domains of both elements.

The steps of defining elements and assembling the structure have organised a data model that is built for both search and detailing. The joint contains elements and nodes, and the elements and nodes contain geometric data. The following section explains joint generation and Reindeer’s class structure.

Joint generation algorithm

Allowing elements to intersect anywhere, including the endpoints, increases the complexity of the programming strategy: The algorithm is required to check if elements intersect somewhere on the curve’s domain. To make the algorithm work, a two-step process was developed. The first step is conventional. When an element is added to the assembly, the code checks if the endpoints exist as nodes. If the node exists, the element is added to its joint. Otherwise, the endpoint is applied to create a node, and the node and element form the basis for creating a joint. The second step takes into account the probability of intersection. All elements must be checked to determine if they intersect with any other elements in the structure. This procedure is simple if the structure is small, but the calculation time exponentially increases when additional elements are added to the assembly.

Figure 5 explains the developed strategy. When an element is added to the assembly and tested for an intersection, the code starts by using an R-tree search, which is a spatial search structure, to filter elements that plausibly intersect. The R-tree stores the element’s bounding sphere in a tree structure and turns searches more targeted towards plausible hits. Visually speaking, an intersection is plausible if the bounding spheres of two elements intersect.

OPEN IN VIEWER

Figure 5.

Finding intersection nodes.

Plausible other elements (OtherElems) are checked if they intersect the new element (ThisElem). The algorithm checks whether the intersected point already exists as a node. If the node exists, the ThisElem is added to the joint (detail). Else, a new node is created, and the node, ThisElem and OtherElem are applied to generate a joint. The joint is then added to the list of AllDetails, and the loop may be repeated.

Class structure

The class structure consists of a main assembly class. The assembly class contains a node class, element class and detail class (see Mork and Luczkowski, ¹⁹ p. 2). A detail and a joint are synonyms in this article: to synchronise the vocabulary with other related researchers, the word joint is used as the relation between elements and nodes. Initially, the word detail was employed and is still applied in the code and the schemes that explain the code.

Identifying joints

The developed solutions let the user define the joint types’ solution space by using one or multiple search criteria components. Conceptually, one component equals the columns in the parallel coordinate diagram. These search criteria filter all joints and pass only the joints that fulfill all search criteria. Mork and Luczkowski ¹⁹ (p. 3) shows two trusses and illustrates how joints are identified using Reindeer.

As the approach does not apply sorting rules but solely depends on the filtering based on the joint’s geometric properties, a parametric detail becomes algorithmically independent from the global topology. If the global topology changes during a design process (What is a sign of a healthy design process?), valid joint instances will be identified if they fulfill the solution space of the joint type.

The power of the search method is revealed when detailing structures without repetitive logic. Figure 6 illustrates a shelf and shell. The shelf shows three different detail types, where the first detail type only requires the detail to be T-shaped. The two other detail types additionally require the angle between the elements to be perpendicular or not perpendicular. A practical example related to this separation is that the perpendicular details can be sawed using a three-axis machine but the angled detail is likely to require a more advanced manufacturing technique.

OPEN IN VIEWER

Figure 6.

JointSearch criteria work, regardless of shape or surface pattern.

The figure shows the same shell that is shown in Figure 4. On the left side, the name of the element is used to find the details that contain an edge. The two other joint searches distinguish the complexity of the joint. Reducing a joint’s maximum number of elements or defining the minimum angle between the elements is likely to reduce the complexity of the node. Table 1 presents the implemented search criteria components.

OPEN IN VIEWER

Table 1.

Search criteria components.

Name	Inputs	Checks
Element length	Min length Max length	Checks lengths of elements and returns true if all elements are within the allowed domain
Element angle	Min angle Max angle	Checks angle between each pair of elements and returns true if pairs are within the allowed domain
Element amount	Min amount Max amount	Checks the number of elements and returns true if the amount is within the allowed domain
Element name	Element names Mode	Checks if the detail’s element’s names correspond to the names of the element. The mode input determines the strictness of the checker. Mode0: The detail’s element’s names must contain one of the inputted names Mode1: The detail’s element’s names must contain at least all inputted names Mode2: The detail’s element’s names must contain all inputted names and no other names Mode3: The detail’s element’s names must correspond exactly to the inputted names
Detail topology	Mode	By choosing a mode, the checker finds details that correspond to typical shape types. The following modes are included: Mode0: L-node: Two elements connected in an endpoint Mode1: T-node: One element is connected at the end, and one element is connected in the middle of the element (not at the ends) Mode2: X-node: Two elements connected on the elements (not at the ends) Mode3: End-node: Nodes with a single element connected Mode4: Star-node: Three or more elements connected at the end Mode5: Planar: All elements can be placed on a single plane Mode6: Orthogonal: All angles between elements in detail are 0, 90 or 180 degrees
Node in region	Region Max offset distance	Checks if the point of the node is inside an inputted region. The inputted max offset distance determines if the point must be on the region or can be offset in the normal direction of the region
Element force components	Max force Min force	Checks if all elements are within the force domain specified by the user. Individual components for Torsion MX, Bending MY, Bending MZ, Compression FX, Tension FX, Shear FY, and Shear FZ.

As shown in Figure 7, each search criterion has one component. The JointSearch is the component that performs the filtering. The criterion is defined and initiated in the SearchCriterion component, sent to the JointSearch component, added to the search criteria list and is performed. The programming strategy is presented by, first, explaining the definition and initialisation of a search criterion, and second, how the criteria are filtering the joints.

OPEN IN VIEWER

Figure 7.

Elements of a search criterion. The top half of the figure shows an ElementAmount criterion.

Initiating search criteria

To be scalable, all search criteria follow a strict format that provides sufficient flexibility. The following points define the format (refer to the bottom of Figure 7):

Questions can only be asked about the joint

The question that is asked is free – the answer must be true or false

The question allows user-defined variables

The method returns a true or false value, and the only input parameter is the joint. As the method is inside the class, all fields are accessible. Figure 8 shows the ElementAmount class and illustrates how the question from Figure 7 is turned into an algorithm. The method checks the number of elements in the joint. IF elements.Count is smaller or equal to minAmount AND elements.Count is smaller or equal to maxAmount, then the method returns a true. Otherwise, the method returns a false. The strictness of the search criteria is attributed to the notion that the method is not initiated immediately but passed to the JointSearch component. The SearchCriterion component does not have information regarding which joint to analyse. Thus, a delegate method is defined with a bool return and a detail as the parameter input. This makes it possible to store methods in a list and run them when appropriate.

OPEN IN VIEWER

Figure 8.

Back-end: class and method. Each rule has a unique class containing field, constructor and method. The fields contain the variables in the question; the constructor initialises the variables to the object, and the method is the logic that answers the question.

When a search criterion object has been initialised, the delegate method is wrapped in a general Rule object and outputted from the component. The Rule object standardises the search criterion and ensures that the input data to the JointSearch is coherent. As a result, new developers can easily code a new search criterion if they construct a method that adheres to the specified delegate format and wraps the constructed method inside a rule object.

In addition to inputting the assembly, the JointSearch component inputs True Criterion and False Criterion. Both inputs are classified as the Rule object type but are stored in lists named ValidProperties and InvalidProperties. If a rule in the ValidProperties list is to be valid, it must return a true. Oppositely, if a rule in the InvalidProperties list is to be valid, it must return a false.

Figure 9 shows the function that filters the search’s valid joints. Each joint is tested against the rules in the ValidProperties list and InvalidProperties list. However, if a rule reveals the joint to be invalid (red field), the loop is broken. Only if the joint passes all rule tests, it is added to ApprovedDetails list (green field).

OPEN IN VIEWER

Figure 9.

The method that filters the joints.

Outputting joints

When detailing a joint, information about the related nodes and elements is required. The more consistently streamed data, the easier the detailing process becomes. An inconsistency often demands codes that handle exceptions from a distinct logic. Three functionalities are implemented to increase the consistency of the data stream: (1) Node plane generators, (2) Unified element vectors and (3) Element sorting rules.

Node plane generators

Defining a node plane is essential in most detailing cases. If a node plane is consistently generated according to its detail’s purpose, the detailing process becomes easier to manage. However, the logic of a node plane varies from case to case. Currently, the Reindeer plugin provides five different methods for generating the node plane. The methods offer various ways for defining the Z- and X-axis of the plane, and the node point determines the location of the plane. Similar to the search criteria component, delegate methods enable the node plane component to grant access to data from the detail.

Unified element vectors

An element has a fixed starting point and endpoint. Thus, a detail will consist of a mix of elements that have their starting point or endpoint at the node’s location. For detailing purposes, utilising vectors that are parallel to their elements but consistently directed from or towards the node is convenient. Thus, the JointSearch component automatically generates and outputs unified element vectors.

Element sorting rules

The order of the elements in detail is initially unstructured. To increase the consistency, the first, second, third and n’th element in each detail instance must correspond. However, a sufficient ordering logic is highly case specific. The current version enables the user to sort (1) clockwise relatively to the node plane, (2) based on structural priority or (3) alphabetically based on element names. Figure 10 exemplifies the importance of these sorting functionalities. The first detail is part of a gridshell structure. Thus, sorting the output of the elements clockwise is probably convenient. The second detail consists of a column, primary beam and secondary beam. In this case, alphabetically sorting the elements will be consistent. The third detail is part of a system with a primary structure, secondary structure and tertiary structure. In this case, sorting based on structural priority is convenient.

OPEN IN VIEWER

Figure 10.

Three different sorting rules for outputting the elements.

Example: outputting data for detailing

The hierarchical construction of the joint makes it easy and logic to deconstruct the joint. The JointSearch component outputs nodes, node planes, elements and unified element vectors as a grafted list (one branch for each joint). The order of the elements and unified element vectors is selected according to the applied sorting rule. Further, the element and node are deconstructed into its properties. Finally, the element can be deconstructed into its subelements. What is required data is individual from detailing to detailing. However, the node plane, width and height, base curve, cross-section plane and side planes of the element are frequently required in the design processes. Mork and Luczkowski ¹⁹ (p. 4) illustrate the data outputted from a truss’ foundation joint.

Example: node in complex shell

A shell, which is shown by Mork and Luczkowski ¹⁹ (p. 5), consists of interior elements and edge elements. The scheme shows how the JointSearch identifies three- or four-legged interior details. Only two criterion components are required: a criterion that defines the element names that are not allowed (edge) and a criterion that specifies the number of elements. The left detail in the figure in Mork and Luczkowski ¹⁹ (p. 5) shows how the JointSearch outputs geometry by default. However, the default joint plane is not applicable, and the order of the outputted elements is not consistent. The right side of the figure is a better basis for detailing. First, the detail plane component has generated a plane based on the shell surface. The X-axis of the plane is aligned parallel to one of the interior elements. Second, the elements are sorted clockwise according to the detailing plane. Note that the element0 is parallel to the X-axis.

Demonstrators

The BottomChord joint type used as example in this article is implemented in two bridges that were designed and built using an early version of Reindeer. These bridges, a ski jump and a log-house, are documented in other articles.^5,20 In the case of the bridges, the joint types were defined using only element name combinations. The joints were filtered based on their properties, and the algorithm was designed to be easily adaptable to both bridges.

Figure 11 shows a parametric timber frame wall (Mork and Luczkowski, ¹⁹ p. 6, shows the related Grasshopper definition). Such structure is not complex from a geometrical point of view. However, from an algorithmic and topological point of view, the structure is more advanced. The example is part of an online shed configurator. When a user orders a shed based on individual inputs, the algorithm automatically outputs pre-cut instructions readable by a CNC machine. With such large design space, it is not feasible to develop a universal sorting algorithm to identify the joints. The example illustrates how joint types are identified in a series of walls with various openings. In this example, a combination of ‘Element Name’, ‘Detail topology’ and ‘Element Amount’ criterion components is used to identify eight joint types. In some sheds, all joint types are needed – in simpler sheds, only a few joint types are needed. These joint types are detailed according to the house manufacturer specifications and outputted as BVX/BTLx-files. The purple joints are identified by specifying what element names to be included or not included in the joint, and that the joint shall be T-shaped and orthogonal.

OPEN IN VIEWER

Figure 11.

Different shed configurations, but a fixed set of possible joint types.

The contrast of the discussed and referred demonstrators indicates that the introduced methodology, implemented in the Reindeer prototype, is applicable for designing a wide range of structures.

Conclusion

This study developed a methodology that efficiently generates topological relations and enables the user to assign joint instances to joint types. The developed prototype, which is based on four steps – defining elements, generating joints, searching for joints and outputting joints – has proven to be flexible despite the simple scheme required to prepare a model for detailing. Other referred tools, such as Elefront, allow efficient geometry filtering. However, these tools lack designated methods for multi-objective filtering of geometric relations. Hence, the presented property-based joint-search methodology is seen as the study’s main contribution.

The notion that the parametric detail becomes algorithmically independent of the global topology is an important advantage. This approach simplifies the process of filtering joint types and substantiates reusing/adapting definitions of parametric joints from projects to projects.

The bridge structures illustrate that the method is applicable for advanced, but logically sound, structures. Further, the timber frame wall demonstrates that the methodology is also applicable for structures that have a less clear topological concept.

The results of this study indicate that the joint-search method is a universal method that is applicable for distinguishing joint types in an arbitrary structure but is dependent on a properly established model that contains topological relations. If a structure is built up by 1D elements and nodes, prototyped software is applicable.

To turn Reindeer more relevant, a future software development must also include cross-laminated timber and other plate-based timber materials. Hence, new joint types and search criteria are also required. Introduced Topologic offers a more comprehensive set of elements in its topology, including wires, faces, shells and cells. Implementing such elements will allow a much larger range of structures. Hence, further research will investigate the potential of combining Topologic’s topology library and Reindeer’s joint-search capabilities.