The Core Principle

Assembler is born out of the intent of distributing granular decision in an open-ended process. It is possible to summarize the core functionality of Assembler with one simple question:

Where do I add the next object?

Assembler places one object at a time, starting from one or more preexisting objects, choosing from the set of possible rules according to given criteria and checking for geometric coherence (clash avoidance).

The Implementation

As trivial as it seems, the core question implies a series of elementary decisions, that can be resumed in 2 general steps occurring at each iteration:

1. select a *receiver *****object (where to add the next object)
2. select a sender object (what kind of object to add and how)

The objects (also referred to as “parts”) in Assembler are called AssemblyObjects. AssemblyObjects use Handles to connect to each other: when an AssemblyObject is considered for assembling it is called a sender, and the object (already in the Assemblage) it connects to is called receiver. Handles include specifics about their connection possibilities, which in turn determine the Heuristics rules of the system.

The algorithm interprets the above steps as follows:

1. select a receiver object in the assemblage according to a specified criterion
2. compare all possible objects that can be attached to the receiver (the "candidates"), compatibly with the constraints in place (for example: avoid clashes with other objects and/or environmental objects), on the basis of the chosen selection criteria (for example: the one that better respects a certain condition) and pick a winner (the sender object)

In short:

• design parts (geometry) and their connection handles (connectivity)
• generate and filter the possible permutation rules
• design the environment in which objects interact
• specify the selection criteria for sender and receiver
• run the Engine
• decide what you want to do with the result (analyze, compute, etc.)

Modularity and strategies

*A computer-aided design system is too often characterised or glorified by its size and its repertoire of operations. A zoo of design services frequently provides the designer with the illusion of generality through sheer quantity of specific routines. [...] As long as the designer never calls for a capacity that is not rightly embedded in the machine, the system will be successful. [...] A well-nourished platoon of specific design operations expects a status quo and excludes a methodological evolution and self-improvement.

Nicholas Negroponte, The Architecture Machine*

A tool is a delicate balance of modularity, generalization and specificity.