Coding for 2D and 3D structures

In the first, 2D version of this work [46], each brick node had a size type parameter (4, 6, 8, 10, 12 or 16, corresponding to the Lego bricks of size through ) and four potential descendants, each one representing a new brick linked at one of its four corners (lower left, lower right, upper right, upper left). Each non-nil descendant had a `joint size' parameter indicating the number of overlapping knobs in the union.

  

Figure 2.12: Example of 2D genetic encoding of bricks (eq. 2.8).

Fig. 2.12 represents a 10-brick with its 4 joint sites labeled 0, 1, 2, 3, that is linked to a 6-brick by two overlapping knobs. The corresponding tree could be written in Lisp-like notation as

$$\text {(10\, nil\, (2\, (6\, nil\, nil\, nil))\, nil\, nil)}$$ (2.8)

For 3D structures we added more size types to incorporate bricks other than (the table experiment in section 2.4.2 had sizes , , , , , , and ), and used a list of descendants, each one representing a new brick to be plugged into the parent. Each descendant brick has 3 parameters: The (x, y, z) coordinates of the new brick (relative to its parent, so for a descendant of an brick, , and z {-1,1}); a rotation parameter that specifies the orientation of the descendant relative to the parent ( ), and the size of the descendant. As an example, the structure in fig. 2.13 can be codified as

$$(1\times 4\, (((3,0,1)\, 90^{o}\, (1\times 2\, (((0,0,1)\, 9... ... {nil})(((1,0,1)\, 270^{o}\, (1\times 2\, \text {nil})))))))))$$ (2.9)

  

Figure 2.13: Model and tree representation for a few Lego bricks (eq. 2.9).