Local heuristic energy function (BRICK ENERGY(cell))

Given a LEGO brick cell placed in the legolized 3D volume LM , the cost of this placement, E_cell, is defined by the following weighted sum equation [5, 10, 11]:

E_cell = W_numBricks× E_numBricks + WdirAltern× EdirAltern

+ WnumDistinctColor× EnumDistinctColor

+ WnumConnBricks× EnumConnBricks

+ WareaConnBricks× EareaConnBricks

+ W_{sameV edge}× E_{sameV edge}

If any of weight equals to zero, then it effectively disable the corresponding energy term. The energy terms often probe the connecting cells from above and below. The

“above” and “below” are following the brick connectivity definition (Def. 2). And the counting of connecting cells are all distinct LEGO bricks, that is, if a vertical connect-ing LEGO brick covers the current evaluatconnect-ing LEGO brick, cell, more than one grids, it should be counted as one rather than the number of overlapping grids. We begin to explain every single energy terms.

The energy term E_numBricks is simply computed by counting how many LEGO bricks in the legolized sculpture volume LM . If the energy term is used in the cellular automaton for local cost function, then it refers to the cost of cell itself. We use uniform cost for each kind of LEGO bricks as the main reference work [5] did. In other word, E_numBricks = 1 for every LEGO brick in LM . We should set WnumBricks > 0 to minimize this energy term. This term can even be ignored when used in cellular automaton because it does not discriminate the merged LEGO bricks, and merging operation itself implicitly and effectively reduce the consumption of LEGO bricks.

The energy term E_dirAltern means the above and below bricks connecting to cell should result in alternative directionality. That is, if the longest dimension of cell is along x-axis, then the above and below bricks connecting to it should have longest dimension along z-axis, and vice versa. Figure 3.20 demonstrate this energy term. The directionality alternation will make the LEGO structure more stable and connected since it follows the principle of masonry. In practice, given the input LEGO brick set, we can compute the longest dimension axis for each kind of LEGO beforehand. E_dirAlternis actually equals to the number of LEGO that differs from cell in longest dimension axis. For LEGO bricks with no longest dimension axis (e.g., squared LEGO bricks like 1x1 and 2x2), this term is ignored. We can infer from the description that we should set W_dirAltern< 0 to maximize this energy term.

The energy term EsameV edge means how many overlapping boundaries for connected LEGO bricks from above and below. Figure 3.21 illustrates this term. The boundaries of LEGO bricks are the reasons why they cannot be horizontally connected. If two connected

(a) Good placement, EdirAltern= 3 (b) Bad placement, EdirAltern= 0

Figure 3.20: The energy term EdirAltern. The cyan arrows represent the longest dimension axis of cell. The black arrows represent longest dimension axes of bricks connecting to cell.

LEGO brick has more overlapping vertical cutting edges, it implies that they are covering themselves. As a result, they are tend to less helpful in increasing connectivity. We should set W_{sameV edge} > 0 to minimize this energy term. We originally implemented E_{sameV edge} by counting the length of total overlapping edges. However, we discovered this energy term will have the side effect of penalizing cell to cover square-shaped LEGO bricks.

Because squared bricks have considerable area covering capability. When cell has to choose a direction from L-shaped choices, this term will cause cell to choose mergeable bricks without covering bricks from above and below. Therefore, we disabled this term in the experiment result by setting W_{sameV edge} = 0

The energy term EnumConnBricksis computed by total number of bricks connecting to cell from above and below. This term directly reflects the connectivity contribution of cell. We should set WnumConnBricks< 0 to maximize this energy term.

The energy term EareaConnBricksis computed similar to the energy term EnumConnBricks, but instead of just adding one for each distinct LEGO brick connecting to cell, it adds the area of vertical connecting LEGO brick. The area is computed as width × length It eval-uates the connectivity contribution more precisely. We should set WareaConnBricks < 0 to maximize this energy term.

(a) Good placement.

E_{sameV edge}= 1

(b) Bad placement.

E_{sameV edge} = 3 + 1 + 3 = 7

(c) Side effect.

Bad merge direction.

Figure 3.21: The energy term E_{sameV edge}. In (a) and (b), cell is the blue LEGO brick.

The red lines show the overlapping edges that should be penalized for bad placement.

However, as (c) shows, this term may make the red LEGO brick to merge the white orphan brick pointed by the arrow, thus increase the risk of disconnection.

The EnumConnBricks and EareaConnBricks terms will drive the cell actively to merge horizontally neighboring cells. Figure 3.22 illustrates the above two energy terms.

(a) Good placement.

EnumConnBricks= 4

EareaConnBricks= 6 + 6 + 2 + 8 = 22

(b) Bad placement.

EnumConnBricks= 3

EareaConnBricks= 1 + 1 + 1 = 3

Figure 3.22: The energy term EnumConnBricks and EareaConnBricks. cell is the light blue brick on the table.

The energy term EnumDistinctColor means to make cell cover as many distinct color of LEGO bricks as possible. It is corresponding to the color extension of the reference work [5]. This is a reasonable energy term because color constraint makes the merging operation more difficult to successfully performed, and thus compromise the connectivity.

Without this term, it is likely that the entire legolized model will split along line partition

by different colors. Note that the “wildcard” color is also treated as one kind of color. We should set WnumDistinctColor < 0 to maximize this energy term. Figure 3.23 shows the example of this energy term.

(a) Good placement.

EnumDistinctColor = 8

(b) Bad placement.

EnumDistinctColor= 2

Figure 3.23: The energy term EnumDistinctColor. The white color here represents the wild-card color. cell is the wildwild-card color sticked to the green plate.

In the original reference work, there was an energy term called Euncovered, which counts the interlocking surface area coverage of cell from above and below. That is, if cell has fewer vertical connecting bricks, the more area is uncovered by LEGO bricks and resulting in larger E_uncovered. However, we feel that this energy term is much less effective, and it may prevent interior cells merge toward boundary. Because boundary bricks often uncovered by other cells to provide shape visual similarity, this term will penalize the outward merging LEGO brick, and thus produce hanging bricks.

In our experiment, our parameters for placement optimization are: MAX ITERATION

= 98, MERGE FAIL LIMIT = 11, W_numBricks = +7, W_dirAltern= −2, W_{sameV edge} = 0 (disabled), WnumConnBricks = +4, WareaConnBricks = −1, and WnumDistinctColor = −2.

Table 3.1 shows the LEGO family set we used in the experiment and its splitting probabil-ity paramters for each kind of LEGO brick. The quantprobabil-ity distribution of the LEGO family set is equivalent to two boxes of LEGO 5623 basic brick set. Our table only considers the dimension, all bricks that has the same dimension but different colors will be aggregated into the total quantity of that dimension. The dimension notation is according to the

Def-inition 3, and we do not mirror the type in the table to reflect the actual number. Figure 3.24 shows our cellular automaton optimization in action. It also illustrates our graphical user interface for this computer-aided LEGO sculpture assembly tool.

Type Quantity Splitting Probability Type Quantity Splitting Probability

1x1x1 128 0

2x1x1 280 0.7 2x1x2 212 0.7

3x1x1 40 0.7 3x1x2 76 0.7

4x1x1 32 0.6 4x1x2 76 0.6

6x1x1 20 0.5 6x1x2 14 0.5

8x1x1 14 0.4 8x1x2 8 0.4

Table 3.1: The LEGO brick family set used in the experiment.

The optimized LEGO placement achieved nearly connected results. However, to fur-ther increase the chance of successfully constructing a LEGO sculpture, we implemented following post-optimization refinement procedures:

1. Repair disconnected hanging LEGO bricks on the surface.

2. Simple L-shaped conflict resolution.

3. Re-merge all bricks generated by above two procedures.

4. Adjust LEGO quantity distribution to relax the pressure from rare kinds of LEGO.

The first procedure is implemented because the optimized placement often consist of fragmented hanging LEGO bricks on the surface, resulting in disconnected legolized model. As shown in Figure 3.27, this kind of artifact is rather easy to repair. We use BRICK CONN COMP to find disconnected components containing only one LEGO brick. Then, for each of such disconnected LEGO brick, we split it and its nearby horizon-tal neighboring LEGO brick. The split operation is defined in Def. 5 and the horizonhorizon-tal neighborhood is defined in Def. 3. After splitting isolated LEGO bricks, we will re-merge them by third procedure rather than reusing the cellular automaton optimization. Because we want to completely avoid the artifact produced by it.

The second procedure is an attempt to repair connectivity lost by L-shaped conflicts, as the bunny example in Figure 3.27 (a). The L-shaped conflict example can be found

(a) layer 8 to 14 optimized

(b) layer 4 to 14 optimized

Figure 3.24: Cellular automaton optimization in action.

in Figure 3.21 (c). What we called “L-shaped conflict” means various problems intro-duced by the lack of L-shaped LEGO bricks. L-shaped voxels introduce conflicts be-cause any of merge results are unable to connect L-shaped voxels, and usually left a (1 × height × m) LEGO brick disconnected. One of resolution methods is to supply a 1x1 brick horizontally that makes L-shaped voxels transformed into squared-shaped vox-els. This is what we did in the second refinement procedure. More clearly, we again apply a BRICK CONN COMP to identify all connected components by integer cell.setid.

Then, we scan entire legolized volume to find possible L-shaped conflicts. If an empty void voxel e(x, y, z) is surrounded by disconnected L-shaped bricks (identified using cell.setid), then we add one 1x1 LEGO at that position.

The third procedure is the brick re-merging algorithm for the first and the second refinement procedure. In order to avoid disconnecting these hanging bricks again, we use a different approach to guide the merge operation. We define another energy called

“risk of disconnection”. Like previously mentioned energy terms in optimization, this term also computes cost by vertical connection condition. For empty void voxels ver-tically neighboring to the brick, we add R for each of such voxel. For 1x1 generic bricks vertically neighboring to the brick, we add 2R for each of such brick. R = max({brick.area | ∀ brick ∈ LEGO family set }) ÷ current brick.area. Unlike pre-viously mentioned energy terms, we also consider horizontal neighboring bricks. We add one for each horizontal neighboring direction that the current brick cannot successfully merge. Figure 3.25 demonstrates how to compute the risk of disconnection of a given LEGO bricks. Please also refer the Definition 3 for related concept.

Provided with the definition of risk above, the algorithm basically performs merg-ing from higher-risk bricks to lower-risk bricks. And the merge must follow the order from higher risk to lower risk strictly (i.e., cell_a.merge(cell_b) is success provided that cella.risk > cellb.risk). We use a priority queue to dynamically maintain the risk or-dering. Initially, the priority queue is filled with all LEGO bricks from the legolized model LM . Then, we perform the merge described above. Newly merged LEGO brick is inserted into the priority queue. After insertion, it updates the risk of bricks near the

+1

Figure 3.25: Risk of disconnection. The white 1x4 brick is the current brick. In (b), there is only one 1x2 yellow brick supporting the center white 1x4 brick. Therefore, +4R is for the added risk for both empty void voxels from above and below.

1x1 1x2

Figure 3.26: Merge closure, computed by the LEGO family set in Table 3.1.

newly merged brick. If the merge operation of a LEGO brick is failed, the brick is simply removed from the priority queue. This procedure is then terminated when the priority queue is empty. Fortunately, this procedure will also merge the smaller LEGO bricks left by previous optimization into larger LEGO bricks. In order to ensure all smaller LEGO bricks are merged into larger ones, we compute the number of merge operation from the set that containing only 1x1 LEGO bricks to the set that containing entire input LEGO family set, or the next set is the same as the current set. We call this “merge closure.”

Figure 3.26 illustrates this computation. The result of our repairing attempt can be found in Figure 3.27.

The fourth procedure is a heuristic greedy adjustment of LEGO brick quantity distri-bution. The idea is to split larger bricks of rare types into smaller bricks of rich types without losing connectivity. We continue splitting until the quantity limits of rare types

(a) Bunny, before repair connected component = 6 number of brick = 191

(b) Bunny, after repair entirely connected number of brick = 165

(c) Child, before repair connected component = 8 number of brick = 324

(d) Child, after repair entirely connected number of brick = 260

Figure 3.27: Post-optimization refinement - connectivity repair.

are satisified. We discovered that 1x3, 1x4, 1x6, 2x6 and 1x8 are rare types, 1x1, 1x2 and 2x2 are rich types. Therefore, we perform the following steps to achieve rare type quantity control.

• Split every 1x3 brick into 1x2 and 1x1.

• Merge every two 1x1 bricks into 1x2 bricks.

• Merge every two 1x2 bricks into 2x2 bricks (if mergeable).

• Split every 1x4 brick into two 1x2 bricks.

• Merge every two 1x2 bricks into 2x2 bricks (if mergeable).

• Split every 1x6 brick into three 1x2 bricks.

• Merge every two 1x2 bricks into 2x2 bricks (if mergeable).

• Split every 2x6 brick into three 2x2 bricks.

• Split every 1x8 brick into four 1x2 bricks.

• Merge every two 1x2 bricks into 2x2 bricks (if mergeable).

Except for the 2x6 split, there are always one or two merge after each split. This is because we want to prevent connectivity instability. However, this conservative sequences may also reduce the chance of successful quantity control.

Finally, to ease the actual construction, we begin to think if there are better building instruction order. We observed that, if we do not have the bottom plate, it is difficult for us to build LEGO structure layer-by-layer, which [5] did. We think a better building order should satisfy:

• Ensure always connected when adding a brick.

• We like to build LEGO structure bottom-up.

According to our observation, we implemented a bottom-up building order by sim-ply a vertical priority breadth-first search of LEGO bricks using undirected connectivity defined in Def. 2.

Chapter 4