# Layout Model Contours

This tutorial presents a process for laying out contour curves generated by slicing a solid model; a procedure that may be applied in various contexts such as producing plan drawings or fabrication profiles. We focus on structuring the process in a semantically clear way using first introducing the typical spaghetti approach and then a more appealing mode using object-oriented methodology.

## Technique

1. Apply the standard operating procedure of defining a geometry bucket and in addition create two lists one for points and one for string such that we can create annotations.
2. Compute the number of slices required by measuring the massing model’s bounding box and dividing its height by the slice size.
3. Define the horizontal cutting plane and an additional layout plane in the XY World plane such that we can perform a plane to plane transformation later. Use modular arithmetic to set the target plane on a rectangular grid.
4. Intersect the solid model with the source cutting plane and transform each curve to its target location (basis or coordinate system).
5. Create an annotation for each target profile with a unique serial number and place its position and text into the annotation buckets.

## Remarks

1. The procedure is in some ways “three dimensional”, in that we iterate three times using a nested for-loop construct. The complexity of this procedure is cubic as it will take ( n x m x l ) steps to process all profiles. Where n is the number of planes, m is the number of solids and l is the number of profiles of intersection.
2. Generally, writing deep nested procedures leads to confusion fairly fast. In particular when the amount of instructions exceed one page and it is no longer easily evident in which level of processing we are operating.
3. There is a better way! We just need to store interim information into data containers, namely lists, and expand the three-loop construct into three flat-loops.
4. In addition we can organize the instructions in such a manner that information has proper semantic logic instead of generic containers.

## Remarks

1. This is rather a large leap from spaghetti to fully organized code but the general logic is rather obvious. We need to define as many levels of abstraction as the number of nested constructs. There is some universal law of conservation of complexity playing out here. Thus we need to capture the notions of a:
1. SLICE which is an entity that contains a list of profile curves (one or many depends on the complexity of the mass) that belong to one unique solid model.
2. LEVEL which is an entity that contains a number of slices that are produced by a single plane and multiple solid bodies.
3. MOLD which is an entity that contains a collection of levels.
2. We then need to take all the sub-processes from the original mono-body code and distribute them in the entities that they logically belong. For example computing the number of slices is the job of the mold.
3. We also perform what is know as cascading delegation of tasks, such that when we ask the mold to contour itself and layout its parts, it, the mold, asks its levels to contour and layout themselves and each of the levels it asks its slices to be computed and layout.
4. The important questions for structuring processes in this fashion are: (a) What IS what and (b) what HAS what. For example a slice can be thought of as either being (IS) a collection of curves or an object which contains (HAS) a collection of curves. Both are valid with a smaller conceptual preference towards the former. In addition is it rather more clear that a slice contains (HAS) a cutting plane, rather then being (IS) a cutting plane.