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).
x translational arrow d
max. cap segment
contact-based
arrows
non-contact
arrows
x
cap arrow
side arrow
x
max. side segment
before arrow
optimization