Wasp Recipes is a work-in-progress approach to defining and reusing sequences within discrete aggregations. By encoding Parts and their connecting Rules, Recipes aim to make it easier to work with closed loops and recurring patterns, particularly when using irregular or reclaimed elements. The goal is to repeat these sequences while allowing them to share Parts with the existing aggregation.

The Sequence Problem

When working with discrete aggregations, and in particular with aggregations of irregular elements, as in the case of waste artifacts, the conventional algorithms used by Wasp encounter a challenge: as the algorihtm is only ever placing one part at a time, and is not able to predict the aggregation result beyond that step, it becomes difficult to create larger sequences of parts which achieve a custom goal, like for example a closed structural loop or a given repetitive pattern of part sequences. This is particularly relevant when working with irregular or reclaimed parts, as these require stricter rules and sequencing to achieve closed loops or repetitive sequences.

A possible solution to this issue is provided in Wasp by the use of Hierarchical Parts, where a higher order Part is built from the combination of other Parts, and is then aggregated as a unit. However, this presents limitations, mainly due to the fact that it is not the Parts sequence that is repeated, but the entire Parts group, meaning that combining two Hierarchical Parts means repeating all sequences on the border between two, instead of using the already placed set of parts as starting and end point for a new sequence. Additionally, moving from working with simple Parts to the use of Hierarchical Parts add a second layer to the Aggregation process, requiring the definition of new rules between the Hierarchical Parts, hence complicating the process.

Encoding Sequences as Recipes

To tackle ths problem, we extended the Wasp toolkit with a new class called Recipe. A Recipe is a pre-defined sequence of Parts, which encodes both the individual Parts, as well as the Rules used to sequentially add one part after another. The distinction is that a Recipe describes how an arrangement is constructed.

These Recipes can be created in a variety of ways:

• Using a pre-computed Aggregation as a fixed sequence to be repeated.
• Creating the desired sequence manually using a Graph-Grammar Aggregation.
• Extracting a sub-set of Parts from a pre-computed Aggregation, identifying either open chains or closed loops to replicate.

These approaches support different ways of designing. We can explicitly define a sequence when we know what we want to construct, or explore an aggregation first and extract an interesting arrangement from its results. In the latter case, a locally discovered pattern becomes an input for further aggregation.

For reclaimed materials, this offers a way to retain useful combinations found within an otherwise irregular system. Once a particular arrangement achieves the desired geometric relationship, we can encode it and explore how it might contribute to a larger assembly.

Aggregating with Recipes

Recipe-based aggregation combines the random selection of Recipes, built from the conventional Wasp Stochastic Aggregation method, with the execution of a predefined sequence of Rules. Instead of independently choosing each next connection, the algorithm follows the relationships stored in the selected Recipe.

When starting from an empty aggregation, the algorithm randomly selects a Recipe and places a copy of its first Part. It then follows the Recipe’s Rules, adding and orienting each subsequent Part according to the specified connections. The sequence can reference previously placed Parts within the Recipe, allowing it to describe arrangements beyond a simple linear chain.

After completing a Recipe, the algorithm randomly selects another one and searches the existing aggregation for suitable starting locations. A candidate must have the same Part name as the Recipe’s first Part and satisfy its start mask. This mask specifies which of the designated connections must be blocked, which must be unblocked, and which can be ignored. One of the matching Parts is then randomly selected as the starting point.

This is the main difference from aggregating Hierarchical Parts: the starting Part already belongs to the aggregation and is reused by the new Recipe. The remaining Parts are added individually, allowing successive Recipe applications to share a starting element without duplicating the entire group or introducing another hierarchy of Parts and Rules.

Each placement is checked against the aggregation’s constraints before it is accepted. If a placement fails, the current Recipe is interrupted and the algorithm attempts to select another Recipe and starting location. Parts already added by the interrupted Recipe remain in the aggregation. Recipes therefore guide the placement sequence, but their execution is not an all-or-nothing operation, and completion is not guaranteed.

The current implementation also adds a new Part for every executed Rule; it does not explicitly recognise an existing Part as the endpoint of a sequence or merge with it. Reusing existing starting Parts is supported, while more general sharing between sequences and explicit loop closure remain areas for further development.

Newly added Parts receive an attribute recording the Recipe name and its application number, making it possible to identify which Recipe application produced them. The process continues until the requested number of Parts has been added, potentially stopping partway through a Recipe, or terminates early if it cannot proceed.

Expanding Aggregation Control

The immediate motivation is greater control over closed loops and recurring sequences, but the broader interest is in moving between local connections and larger patterns. A Rule describes how two Parts can connect. A Recipe captures an arrangement involving several Parts. This gives us an intermediate level of control: enough to describe a meaningful sequence while continuing to work with individual elements.

For irregular and reclaimed materials, that could help us explore how specific combinations contribute to larger assemblies. A closed geometric loop might become a starting point for structural investigation, although its closure alone says nothing about its load-bearing performance. A recurring chain might establish a spatial rhythm, or connect larger arrangements through shared elements.

Work in Progress

Wasp Recipes is still under development and separated from the main Wasp development branch. The code can be found on the wasp-recipe branch of the Wasp repository, as well as a fork on the Inventorics Github page. The questions we are exploring include how sequences should match existing Parts, how to handle sequences that cannot be completed, and how multiple Recipes might interact within the same aggregation.

The wider ambition is to make sequences something we can design, extract, inspect, and reuse. This would allow useful arrangements discovered during exploration to become part of the logic guiding the next aggregation.