CLUSTER 2: Manual Aggregations with Blocks

| Andrea Rossi

In order to simplify rules definition for Wasp Parts with a high number of connections, we implemented a new method which allows to manually aggregate Parts in Rhino, and automatically detect rules from this manual Aggregation structure.

A New Way to Define Aggregation Rules

During the exploration of possible designs for a new detergent bottle, able to become a reusable building block, we encountered a challenge: in order to have maximum flexibility in the assembly, each bottle has a high number of possible connecting faces to other blocks, resulting in a very large search space. This becomes an issue particularly when using Wasp, as the large number of combinations results in a very large Rules set, which makes it difficult to control the Aggregation, and often results in longer compute time for generation.

While we tried several approaches, like arbitrarly choosing a limited subset of Connections, or stochastically removing a given number of Rules, all approaches resulted in a very limited control on the overall Aggregation, as well as in limited flexibilty and increased complexity.

To tackle this issue, we implemented a novel approach which does not require to explicitcly define Aggregation Rules in Grasshopper, but which is able to automatically detect Rules from a combination of 3d geometries in Rhino. To do this, we implemented a process which allows to “bake” a Wasp Part definition as block in Rhino, track its duplicates and their relative transformations, and then load them back into Grasshopper and replace the loaded blocks with the initial Part definitions.

Fig. 01: Bottle Block part baked as Rhino Block and manual assembly of blocks. Connection axes are also baked to allow for easier manual assembly.

Once loaded back in Grasshopper, the manually aggregated Parts can be evaluted to detect which Connections are currently overlapping between each pair of Parts. These are assessed against set tolerance values for both position and rotation, which enable to account for accuracy issues during manual modelling. If two Connections between a given pair of Parts overlap within the tolerance values, they are considered connected, and hence a Rule is automatically defined between them, allowing to replicate the exact relative position as an Aggregation step.

Fig. 02: Overview of the new Grasshopper components to bake and reload Parts, and to extract the Rules from the “manual” Aggregations.

However, a second challenge which is specific to the space-filling patterns used for the proposed bottle designs, is the fact that several rules result in the same exact relative configuration between two connected parts. This is due to the fact that, in the same configuration, several Connection pairs are actually overlapping, causing a very large list of Rules, which however do not result in geometric differences. For this reason, a filter was implemented which was able to detect all Rules resulting in an identical geometric configuration, and remove them, leaving only one valid rule for each configuration.

Fig.03: Left, all rules detected from four manually aggregated Parts; right, the rules after filtering for duplicates and rules creating the same configuration.
Fig. 04: Different aggregations generated with the same filtered rules set.

Currently this design process is implemented as a set of custom IronPython nodes in Grasshopper. However, it will be soon integrated as part of one of future Wasp releases as a standard component.

Beyond Rules Definition

While the key advantage of this method is to provide a tool to quickly define Aggregation rules in 3D space without need for manual typing, the tool also provides other possible applications. One example is the possibility of using this tool to manually place starting points for an aggregation, removing the need to use the TransformPart component in Wasp, which often requires a good understanding of how transformations work in Grasshopper

Fig. 05: Manually placed parts in Rhino (left) and resulting aggregation using these parts as starting point.

Another opportunity provided by baking and reloading parts is the possibility of not only learning individual rules, but also entire rule sequences, which could then be executed to generate entire Aggregation chunks at once. This requires changes in the internal Wasp algorithms, which are being developed within the project and will be explored in future posts.