Communications - January 2013

compute the contact relationships at each time. We use a fixed sampling rate of D = 0.1 s with the default speed for the driver part set to an angular velocity of 0.1 radian/s or translational velocity of 0.1 unit/s, as applicable. Our method detects cases where two parts transition from touching to not touching over time. It also detects cases where two parts remain in contact but their contact region changes, which often corresponds to a change in the parameters of the mechanical interaction (e.g., the variable speed gear shown in Figure 3). For each set of detected contact relationships, we compute a new interaction graph. Note that we implicitly assume that part contacts change discretely over the motion cycle, which means that we cannot handle continuously evolving interactions, as in the case of elliptic gears. See original paper23 for additional details.

(ii) interaction classification. We classify the type of interaction for each pair of parts Pi and Pj that are in contact, using their relative spatial arrangement and the individual part attributes. Specifically, we classify interactions based on the positions and orientations of the part axes ai and aj along with the values of the relevant part parameters. For parts with multiple potential axes, we consider all pairs of axes.

Parallel axes: When the axes are nearly parallel, that is, |ai · aj| ≈ 1, we detect one of the following interactions: cylinder-on-cylinder (e.g., spur gears) or cylinder-in-cylinder (e.g., planetary gears). For cylinder-on-cylinder, ri + rj (roughly) equals the distance between the part axes. For cylinder-in-cylinder, |ri − rj| (roughly) equals the distance between the part axes. Note for cylinder-on-cylinder, the parts can rotate about their individual axes, while simultaneously one cylinder can rotate about the other one, for example, (subpart of) planetary configuration (see Figure 9).

Coaxial: When the axes are parallel and lie on a single line, we classify the interaction as coaxial (e.g., spur–axle and cam–axle).

Orthogonal axes: When the axes are nearly orthogonal, that is, ai · aj ≈ 0, we detect one of the following interactions: spur–rack, bevel–bevel, helical–helical, helical–spur. If one part is a rotational gear and the other is a translational gear with matching teeth widths, we detect a spur–rack interaction. If both parts are conical with cone angles summing up to 90°, we mark a bevel–bevel interaction. If both parts are cylindrical and helical, we mark a helical–helical interaction. If the parts are cylindrical but only one is helical, we mark a helical–spur interaction.

Belt interactions: Since belts do not have a single consistent axis of motion, we treat interactions with belts as a special case. If a cylindrical part touches a belt, we detect a cylinder-on-belt interaction.

These classification rules are carefully designed based on standard mechanical assemblies and successfully categorize most part interactions automatically. In our results, only the cam–rod and piston–crank interactions in the hammer (Figure 7a), piston engine (Figure 8), and the drum (Figure 10d) needed manual classification.

(iii) Motion computation. Mechanical assemblies are brought to life by an external force applied to a driver and propagated to other parts according to interaction types and part attributes. In our system, once the user indicates

y
z
r

q

y
z
r

q

z y

the driver, motion is transferred to the other connected parts through a breadth-first graph traversal of the interaction graph G, starting with the driver-node as the root. We employ simple forward-kinematics to compute the relative speed at any node based on the interaction type with its parent5. For example, for a cylinder-on-cylinder interaction, if motion from a gear with radius ri and angular velocity wi is transmitted to another with radius rj , then the imparted angular velocity wj = wiri/rj . Our approach handles graphs with loops (e.g., planetary gears). Since we assume that our input models are consistent assemblies, even when multiple paths exist between a root node and another node, the final motion of the node does not depend on the graph traversal path. When we have an additional constraint at a node, for example, a part is fixed or restricted to translate only along an axis, we impose the constraint in the forward-kinematics computation. Note that since we assume that the input assembly is a valid one and does not self-penetrate during its motion cycle, we do not perform any collision detection in our system.

5. VisuaLiZatioN

Using the computed interaction graph, our system automatically generates how-things-work visualizations based on the design guidelines discussed in Section 2. Here, we present algorithms for computing arrows, highlighting both the causal chain and important keyframes of motion, and generating exploded views.

5. 1. Computing motion arrows

For static illustrations, our system automatically computes arrows from the user-specified viewpoint. We support three types of arrows (see Figure 6): cap arrows, side arrows, and translational arrows and generate them as follows: (i) determine how many arrows of each type to add; (ii) compute initial arrow placements; and (iii) refine arrow placements to improve their visibility.

For each non-coaxial part interaction encoded in the interaction graph, we create two arrows, one associated with each node connected by the graph edge. We refer to such arrows as contact-based arrows, as they highlight contact

figure 6. translational, cap, and side arrows (left). arrows are first added based on the interaction graph edges, and then to any moving parts without an arrow assignment. the initial arrow placement can suffer from occlusion (right-inset), which is fixed using a refinement step (center).