Rigidity Investigations
in Virtual Lego Models
MATTIAS
JOSEFSSON
Master of Science Thesis
Stockholm, Sweden 2006
Rigidity Investigations
in Virtual Lego Models
MATTIAS
JOSEFSSON
Master’s Thesis in Computer Science (20 credits)
at the School of Engineering Physics
Royal Institute of Technology year 2006
Supervisor at CSC was Stefan Nilsson
Examiner was Johan Håstad
TRITA-CSC-E 2006:109
ISRN-KTH/CSC/E--06/109--SE
ISSN-1653-5715
Royal Institute of Technology
School of Computer Science and Communication
KTH CSC
SE-100 44 Stockholm, Sweden
URL: www.csc.kth.se
Abstract
Rigidity investigations in virtual Lego models
In this thesis, we investigate the potential improvement of the algorithms detecting rigid structures in virtual Lego models in the computer
application Lego Digital Designer.
First, the previously achieved results are presented. This mainly
involves a heuristic triangle rigidity detection algorithm described in a
Bachelor’s thesis.
Then, the two theoretical fields framework rigidity and generic rigidity are examined. The aim is to apply them to virtual Lego models. The
two theoretical fields face different obstacles. Framework rigidity does
not seem suitable for detecting rigid structures; it also suffers from its
dependence on the rank computations of a matrix that can grow very
large and its compliance with infinitesimal rigidity instead of the kind
of rigidity desired in the application. Generic rigidity most importantly
fails because of its loss of geometric information, which leads to incorrect
calculations of rigidity properties, and the fact that Laman’s theorem
does not generalize to three dimensions for general graphs.
Finally, a heuristic approach is chosen. A rigidity detection algorithm for so-called “prism structures” is presented in pseudo code. The
worst-case time complexity for the algorithm to detect prism rigidity after a brick has been added is O(r3 ), where r is the number of previously
detected rigid structures in the model.
We conclude that the emphasis of future research should be put
on heuristic approaches, e.g. treating three-dimensional structures with
four (or more) one-dimensional joints, the removal of bricks, and the
consequences of adding the domain of Technics bricks to the Digital
Designer application.
Referat
En utredning av rigiditet i virtuella Lego-modeller
I den här rapporten undersöks möjligheterna att förbättra algoritmerna
för detektion av rigida strukturer i virtuella Lego-modeller i datorapplikationen Lego Digital Designer.
Först presenteras tidigare uppnådda resultat. I huvudsak behandlas
en heuristisk algoritm som detekterar triangelrigiditet och som beskrivits i en tidigare kandidatuppsats.
Sen undersöks två teoretiska fält, ramverksrigiditet och grafrigiditet.
Syftet är att tillämpa dem på virtuella Lego-modeller. De två teoretiska
fälten står inför olika problem. Teorin för ramverksrigiditet verkar inte
kunna användas för att detektera rigida strukturer; teorin lider också
av sitt beroende av rangberäkningen av en matris som kan växa väldigt
stor och av sin överensstämmelse med infinitesimal rigiditet i stället för
med den rigiditet som önskas i applikationen. Teorin för grafrigiditet
misslyckas huvudsakligen på grund av sin förlust av geometrisk information, vilken leder till felaktiga beräkningar av rigiditetsegenskaper,
och det faktum att Lamans sats inte gäller i tre dimensioner för generella
grafer.
Slutligen väljs en heuristisk infallsvinkel. En algoritm för rigiditetsdetektion av så kallade “prismastrukturer” presenteras i pseudokod.
Tidskomplexiteten för algoritmen att detektera prismarigiditet efter att
en kloss har lagts till är i värsta fall O(r3 ), där r är antalet tidigare
detekterade rigida strukturer i modellen.
Slutsatsen är att tonvikten för framtida forskning bör läggas på
heuristiska infallsvinklar, som t.ex. behandlar tredimensionella strukturer med fyra (eller fler) endimensionella sammanfogningspunkter, borttagning av klossar och konsekvenserna av att mängden av Technicsklossar läggs till i applikationen Digital Designer.
Preface
This Master’s thesis was written at the department for Informatics and Mathematical Modelling (IMM) at the Technical University of Denmark (DTU) in Lyngby,
Denmark. I attended the Master of Science Program in Engineering Physics at the
School of Computer Science and Communication (CSC) at the Royal Institute of
Technology (KTH) in Stockholm, Sweden and studied abroad at DTU during my
Master’s project.
The problem described in this thesis is the result of a collaboration between the
Lego® Group (Lego) and IMM. However, no communication with Lego has taken
place in connection with this project; the thesis has been written solely at IMM.
I would like to express my gratitude to Assistant Professor Thomas Bolander,
the supervisor of this project at IMM, DTU, for the hours of assistance and his
seemingly endless enthusiasm.
I would also like to thank Doctor Stefan Nilsson, the supervisor of this project
at CSC, KTH, for his swift communication and helpful comments.
Last but not least, I dedicate this thesis to Gunhild. For many reasons, its
existence would not have possible without you.
M.Sc. Student Mattias Josefsson, June 2006
Contents
Contents
1 Introduction
1
2 Definitions
3
3 Previous results
3.1 Rules for rigidity . . . . . . . . . . . . .
3.1.1 Rules implemented by Lego . . .
3.1.2 Triangle rigidity rule . . . . . . .
3.1.3 Rules currently not implemented
3.2 Model . . . . . . . . . . . . . . . . . . .
3.2.1 Class hierarchy . . . . . . . . . .
3.2.2 Rigidity detection levels . . . . .
3.3 Triangle rigidity detection . . . . . . . .
3.3.1 Implementation . . . . . . . . . .
3.3.2 Time complexity . . . . . . . . .
3.3.3 Limitations . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
6
8
9
9
10
11
11
13
14
4 Applying theory
4.1 Framework rigidity . . . . . . . . . . . . . .
4.1.1 Rigidity and infinitesimal rigidity . .
4.1.2 Computing infinitesimal rigidity . .
4.2 Applying framework rigidity . . . . . . . . .
4.2.1 Representing Lego models . . . . . .
4.2.2 Implications of infinitesimal rigidity
4.2.3 Rigidity matrix size . . . . . . . . .
4.2.4 Detecting rigid structures . . . . . .
4.2.5 Conclusion . . . . . . . . . . . . . .
4.3 Generic rigidity . . . . . . . . . . . . . . . .
4.3.1 Generic rigidity in two dimensions .
4.3.2 Generic rigidity in three dimensions
4.4 Applying generic rigidity . . . . . . . . . . .
4.4.1 Representing Lego models . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
19
19
21
23
23
25
29
29
30
30
30
40
41
41
.
.
.
.
.
.
.
.
.
.
.
4.4.2
4.4.3
4.4.4
Loss of geometric information . . . . . . . . . . . . . . . . . .
Generic rigidity in three dimensions . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Prism rigidity detection
5.1 Rigidity rule . . . . . . .
5.2 Prerequisites . . . . . .
5.3 Algorithm . . . . . . . .
5.3.1 Time complexity
5.3.2 Implementation .
5.4 Relevance . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
43
43
44
44
45
45
48
49
49
6 Conclusion
51
Bibliography
53
A Triangle rigidity test model data
55
B Matlab program for rigidity matrix rank computation
57
Chapter 1
Introduction
In 2004, the department of Informatics and Mathematical Modelling (IMM) at the
Technical University of Denmark (DTU) began a collaboration with the Lego Group
(Lego) concerning the application Lego Digital Designer [10]. One of the results of
the collaboration is a report describing several of the problems faced in the creation
of the application [16].
Digital Designer lets the user create virtual Lego models using a computer.
There already exists a functioning version of the application; however, the further
development of the application requires deeper studies of certain theoretical problems within algorithmics and graph theory.
One of the requested properties for Digital Designer is that the models should be
able to move realistically. The latest release of the application only supports static
models; however, a version of the application that supports motions of the models
is under development. The motion calculations in this version are performed by a
physics engine.
Presently, the physics engine is forced to perform unnecessary motion calculations among bricks that are actually rigid relative each other. Consequently, the
limit for when the application slows down considerably is unreasonably low. An
improvement of the motion calculations, resulting in an application simulating the
motions of larger Lego models in real time on an average PC, would potentially
enhance the functionality of the application significantly.
Problem definition
To render the motion calculations in the Digital Designer application more effective,
one would like to improve the detection of rigid structures. A rigid structure is a
set of bricks in which no brick can move relative any other brick in the set; in other
words, if one brick in the set is subjected to a translation or rotation, then all the
other bricks in the set are subjected to the same motion. Rigid structures can be
seen as larger, more complex bricks—super bricks. That consequently reduces the
number of bricks for which the physics engine must calculate the motions. Creating
1
new algorithms that detect rigid structures in Lego models is the main aim of this
thesis. This problem shall later be referred to as the rigidity problem.
The rigidity problem is limited to structures consisting of rigid bricks and onedimensional joints (connection points with a fixed rotational axis). The situation
with two-dimensional joints (ball-and-socket joints) is not discussed here. The problem is further limited to a focus on two-dimensional (plane) structures, i.e. structures where all rotational axes are parallel. Three-dimensional structures are only
discussed briefly. No implementation is presented; we examine the problem from a
strictly algorithmic viewpoint. Also, the motion calculations are not brought up as
part of the thesis. They are assumed to be performed—as is presently the case—by
the physics engine that is incorporated in Digital Designer.
Method
In order to create new rigidity detection algorithms, we first and foremost perform
a search in scientific articles for relevant theory. In detail, we try to apply two theoretical areas—framework rigidity and generic rigidity—to virtual Lego models. The
obstacles discovered in this process are described. As the application of the theoretical areas is found fruitless, we turn to a heuristic approach for the improvement
of the existing rigidity detection algorithms.
2
Chapter 2
Definitions
In order to discuss rigidity in Lego models, we need to define a few concepts. The
following definitions are to a large extent according to [8].
A brick is simply a Lego brick, which can connect to other bricks via its connection points. A connection point is a shape on the brick which together with
a fitting shape on some other brick enables the two bricks to stick together. A
connection arises when two bricks are joined via fitting connection points on each
brick. A connection can either be rigid or flexible. It is rigid if the bricks that are
connected cannot translate or rotate relative each other, otherwise it is flexible. If a
connection is flexible and it is possible to rotate the bricks around the connection,
the axis around which the rotation occurs is called the rotational axis.
It is important to distinguish between parallel and coincident rotational axes.
a)
b)
Figure 2.1. Examples of parallel and coincident rotational axes. In (a), there are
four parallel rotational axes. They are situated in the corners of the structure and
are all perpendicular to the surface on which the structure rests. In (b), there are
three rotational axes. The first one is in the connection between the dark top brick
and the light 1 × 10 brick pointing to the left. The second one is in the connection
between that 1 × 10 brick and the 1 × 10 brick directly below it. The third one is
between the latter 1 × 10 brick and the flat brick at the bottom. All three rotational
axes are perpendicular towards the surface and thereby parallel. Since they all have
the same position, they are also coincident.
3
Coincident rotational axes are always parallel, but parallel rotational axes are not
necessarily coincident. For example, Figure 2.1(a) shows a model where all rotational axes are parallel (but not coincident). The four rotational axes are located
in the corners of the structure and are perpendicular to the surface on which the
structure rests. In Figure 2.1(b), all rotational axes are coincident (and thereby
also parallel). There are three rotational axes in the model. The first one is in the
connection between the dark top brick and the light 1 × 10 brick pointing to the
left. The second one is in the connection between that 1 × 10 brick and the 1 × 10
brick directly below it. The third one is between the latter 1 × 10 brick and the
flat brick at the bottom. All three rotational axes are perpendicular towards the
surface and thereby parallel. Since they all have the same position, they are also
coincident.
Finally, a structure is a connected set of bricks. When we refer to a structure,
this set of bricks may well be a subset of a larger structure.
The definitions presented here concern virtual Lego models in general. When we
go further into theoretical areas, e.g. graph theory, we need more specific definitions.
These definitions are presented later in this thesis, as they are needed.
4
Chapter 3
Previous results
The account of previous results in this chapter is based on a Bachelor’s thesis
presented at the University of Southern Denmark in September 2005 [8]. Unless
otherwise stated, the results presented here are from this source.
3.1
Rules for rigidity
Rigidity in virtual Lego models is defined as follows.
Definition 3.1 (Lego rigidity) In a rigid structure, the following is true for all
bricks.
1. A translation of one brick implies the same translation of all the other bricks
in the structure.
2. A rotation of one brick implies the same rotation of all the other bricks in the
structure.
A set of rules for when a structure is rigid is defined in [8]. It is noted that these
rules do not give a complete detection of rigid structures in Lego models.
3.1.1
Rules implemented by Lego
Some rigidity-detection rules were implemented by Lego before [8] was written.
Three of these rules are described; simple rigidity, detection of double connections
and the approximation of 1 × 1 bricks as being symmetric.
Simple rigid structure
A brick by itself constitutes a rigid structure. This rule is rather obvious, but this
statement allows us to formulate the following rules in terms of connected rigid
structures instead of connected bricks.
5
Figure 3.1. Example of a rigid structure in which there are only double connections.
Double connections
If two rigid structures have two connections without coincident rotational axes between them, then the two rigid structures form a single rigid structure.
This type of connection between bricks is common among Lego models. An
example of a structure consisting only of double connections between bricks is shown
in Figure 3.1. The figure shows five bricks. The flat brick in the middle has a
double connection to each of the bricks perpendicularly connected to it. Therefore,
the three bricks constitute a rigid structure. The two bricks that are parallel to the
flat brick each have a double connection to this structure, and so all the bricks in
the figure form a single rigid structure.
1 × 1 bricks
If a brick has a width of one Lego unit and a length of one unit, then it is a 1×1 brick.
Some bricks of this kind are symmetric around their rotational axes. A rotation
of such a brick around its rotational axis does not visibly change its alignment in
space. Therefore, if a symmetric 1 × 1 brick is connected to another brick, then the
two bricks together form a single rigid structure.
Despite the fact that a 1 × 1 brick is not necessarily symmetric around its
rotational axis, Lego has implemented a rule that approximates all 1 × 1 bricks to
be symmetric around their rotational axes. Hence, all rigid structures connected to
a 1 × 1 brick form a rigid structure together with the brick.
3.1.2
Triangle rigidity rule
The main result in [8] is the implementation of two different algorithms that detect
triangle rigidity. They are based on the rule described in this section.
6
Figure 3.2. An example of a triangle structure in which no rotational axes are
coincident.
Figure 3.3. An example of a triangle structure in which two rotational axes are
coincident.
Figure 3.4. An example of a triangle structure in which all three rotational axes
are coincident.
7
Triangle rigidity
Three rigid structures A, B and C can potentially form a triangle. In order for that
to be the case, there must be three connections between the structures—between
A and B, between B and C, and between A and C. Only flexible connections are
interesting here. If there is a rigid connection, then two of the structures form a
single rigid structure, which now has a double connection to the third rigid structure,
making the whole structure rigid on the grounds of double connections.
If a triangle is formed, there are possibilities for rigidity. There are three cases:
none of the rotational axes are coincident, two rotational axes are coincident and
all three rotational axes are coincident.
If no axes are coincident, then the triangle forms a single rigid structure. An
example of this is shown in Figure 3.2.
If two rotational axes are coincident, then the structure between these connections can rotate around this axis. The two other structures can also rotate together
around the axis, but they cannot move relative each other and therefore constitute
a rigid structure. An example of this can be seen in Figure 3.3.
If all three rotational axes are coincident, then the three structures can rotate
independently around this axis, and no rigidity is detected. An example of this is
presented in Figure 3.4.
3.1.3
Rules currently not implemented
Two rules are currently not implemented in the Digital Designer application; detection of symmetric structures and detection of physical rotational limitations between
structures. There are further possible rules for rigidity, but these are the rules described in [8].
Symmetric bricks
It is possible to imagine other symmetric bricks than 1 × 1 bricks. A rotation of
such a brick around its rotational axis would not visibly change its alignment in
space. However, for two main reasons the detection of general symmetric bricks
has not been implemented. First, in order for such a detection to be possible, one
must have information about which bricks are symmetric and around which axes
the symmetry occurs. The application does not currently contain such information
about each type of brick. Second, there are very few bricks that are symmetric
around their rotational axes. (Neither in [8] nor here has a symmetric brick that is
not a 1 × 1 brick been found—and 1 × 1 bricks have already been treated, as stated
earlier in this chapter.)
Physical rotational limitations between structures
Given a set of connected rigid structures where relative rotations around the rotational axes of the connections between the structures are not possible because of the
8
Figure 3.5. An example of how the physical shape of the bricks can make a structure
rigid, despite the possibilities of rotation indicated by the connection structure.
shape of the structures, the structures together make up a single rigid structure.
Figure 3.5 shows three bricks. The 1 × 10 brick has only one connection to the
rigid structure consisting of the other two bricks. A rotation of the brick around
the rotational axis of the connection should therefore be possible. However, due to
the shape of the bricks, no such rotation is possible and the three bricks make up a
single rigid structure.
The physical rotational limitations between structures are not related to the
connection of bricks, but rather the shape of the bricks in question. Therefore, it
seems reasonable not to implement detection of this kind of rigidity, but to let the
existing physics engine handle the task.
3.2
Model
The model used by Lego to represent a set of bricks consists of two parts; one
part contains information about connections between bricks and the other contains
information about the shape and appearance of the bricks. We are interested in the
first one.
3.2.1
Class hierarchy
Connections between bricks are modelled via several levels.
PrimitiveElement - An instance of the class PrimitiveElement is a brick.
PrimitiveRigidElement - An instance of the class PrimitiveRigidElement is a
set of bricks (PrimitiveElements) that are rigid relative each other through
double (or higher-order) connections. The rigidity detection on this level was
already implemented by Lego.
RigidElement - An instance of the class RigidElement is a rigid set of PrimitiveRigidElements. This is the level on which the triangle rigidity detection is
implemented in [8].
9
HingedElement - An instance of the class HingedElement consists of a set of
RigidElements, where the connections between these are flexible (according
to the current implementation).
Scene - An instance of the class Scene is a set of HingedElements that are not
connected.
Instances of the classes PrimitiveRigidElement, RigidElement, HingedElement and Scene hold references to the objects that the instances contain. There
are only references to objects of the class directly below the current level. Through
each of these objects, one has access to the objects one level further down in the
model.
Instances of the classes PrimitiveElement, PrimitiveRigidElement and RigidElement hold information about which connections the instances have. These
are connections to objects on the same level in the model.
3.2.2
Rigidity detection levels
The rigidity detection implemented by Lego before [8] was written is local. In other
words, when a brick is added to the model, the detection of new rigid structures
takes as starting point the connections of the added brick. The procedure works
recursively, i.e. if rigidity is detected through the added brick, then the connections
of the newly formed rigid structure are examined for possible further rigidity, and
so on. In other words, a complete analysis of all parts of the model only occurs if
rigidity is detected in each new step of the procedure.
When a brick is added, a new PrimitiveElement object is created. If the
added brick is connected to other bricks, then double connections to other bricks
are first detected. If the brick has double connections to a rigid structure, then the
brick is added to the PrimitiveRigidElement in question. If there are no rigid
connections to other structures, then a new PrimitiveRigidElement is created for
the new brick.
When the detection on the PrimitiveRigidElement level is finished, the detection can continue on the RigidElement level. This detection takes place if the
added brick has led to changes on the PrimitiveRigidElement level. Among the
current rigid structures, detection of double connections and triangles is performed.
If rigidity through one of these connection forms is detected, then the structures in
question are merged into a single rigid structure. The connections to other structures from this new rigid structure can in turn lead to new rigid structures being
detected, and this is how the we end up with a recursive procedure.
10
3.3
Triangle rigidity detection
Triangle rigidity detection is implemented and described in detail in [8]. In this
section, we look at the two triangular detection implementations from a broader
perspective, briefly examine the runtime of the implementations and discuss some
limitations of triangle rigidity detection.
3.3.1
Implementation
Two methods for triangle detection were implemented, CheckForTriangles and
CheckForTrianglesMapImplementation. The two methods have the same functionality, but they detect triangles in two different ways. They are both called from
the function OptimizeStructure.
OptimizeStructure
The function OptimizeStructure (shown in Figure 3.6) is responsible for calling
the triangle rigidity algorithms. OptimizeStructure takes as parameter the rigid
structure that an added brick is a part of after double connection rigidity has been
detected (line 01). Thereby, we also have the connections leading away from that
rigid structure (line 02). As long as there are any interesting connections to examine
(line 03), a temporary reference ready for further interesting connections is initialized (line 04); then, the connections away from the rigid structure of the added brick
are iterated through (line 05), the rigid structure on the other side of the current
connection is stored (line 06), and one of the triangle rigidity detection algorithms is
called (in this case CheckForTriangles) (line 07). During this call, rigid structures
may be merged. However, the stored interesting connections are still gone through,
since they can lead to further merging of rigid structures. When all connections
leading away from the original rigid structure have been iterated through, any new
interesting connections are stored (line 08–09), and the procedure is repeated for
these connections.
CheckForTriangles
Of the two triangle rigidity detection algorithms, we have chosen to focus on CheckForTriangles (shown in Figure 3.7). This is because, as we observe in Section 3.3.2,
this algorithm is almost always faster than its map implementation alternative. The
foundation of the algorithm is that it tries to find the original rigid structure at a
distance three rigid structures away from itself. If this succeeds, then a triangle is
detected, and its rigidity properties are examined.
The algorithm takes as parameters a connection, the rigid structures on each side
of the connection, and a reference to store new interesting connections in (line 01).
Via the second rigid structure we have the connections leading away from that
structure (line 02), and these connections are iterated through (line 03).
11
01 Function OptimizeStructure(rs1)
02
conns1 = rs1.GetConnections()
03
While (Not conns1.IsEmpty())
04
Connections[] conns0
05
For Each conn1 In conns1
06
rs2 = conn1.GetRigidStructure()
07
CheckForTriangles(conn1, rs1, rs2, conns0)
08
Reset conns1
09
conns1.Swap(conns0)
Figure 3.6. Function OptimizeStructure for detecting triangle rigidity.
We check that the current connection does not lead back to the original rigid
structure (line 04); if it does not, then we store the rigid structure on the other side
of the connection (line 05), store its connections (line 06), and iterate through these
connections (line 07).
After checking that the rigid structure on the other side of the current connection
is not the previous rigid structure in the path (line 08), we store the rigid structure
on the other side of the current connection (line 09) and check if that connection is
the original rigid structure (line 10). If that is the case, we have found the original
rigid structure at a distance three rigid structures away from itself, and thus a
triangle is detected.
We now examine the rigidity properties of the detected triangle. If no pair of
connections among the three connections in the triangle have coincident rotational
axes (line 11), then we merge all three rigid structures in the triangle (line 12), store
the connections leading away from the newly formed rigid structure (line 13), and
exit the algorithm (line 14). If, on the other hand, one pair of connections among
the three connections in the triangle have coincident rotational axes (line 15), then
we merge the two rigid structures that are not directly between the two coincident
connections (line 16), store the connections leading away from the newly formed
rigid structure (line 17), and exit the algorithm (line 18).
CheckForTrianglesMapImplementation
The difference between CheckForTriangles and CheckForTrianglesMapImplementation is the way the algorithms detect triangles.
CheckForTrianglesMapImplementation makes use of the fact that the connections away from a structure on the Rigid level constitute a mapping from RigidElements to RigidConnections. Since the algorithm receives as parameters references
to two rigid structures, we can look up a neighbouring rigid structure to one of the
structures in the mapping of the other structure. If there is a match, a triangle has
been found.
The examination of the rigidity properties of the detected triangle is performed
12
01 Algorithm CheckForTriangles(conn1, rs1, rs2, conns0)
02
conns2 = rs2.GetConnections()
03
For Each conn2 In conns2
04
If (rs1 6= conn2.GetRigidStructure(rs2))
05
rs3 = conn2.GetRigidStructure(rs2)
06
conns3 = rs3.GetConnections()
07
For Each conn3 In conns3
08
If (rs2 6= conn3.GetRigidStructure(rs3))
09
rs4 = conn3.GetRigidStructure(rs3)
10
If (rs1 == rs4)
11
If (no pair in {conn1, conn2, conn3}
has coincident rotational axes)
12
Merge all three rigid structures
13
Store the new rigid structure’s
connections in conns0
14
Exit
15
Else If (one pair in {conn1, conn2, conn3}
has coincident rotational axes)
16
Merge the two rigid structures
that are not between
the coincident connections
17
Store the new rigid structure’s
connections in conns0
18
Exit
Figure 3.7. Algorithm CheckForTriangles for detecting triangle rigidity.
in the same way as in CheckForTriangles. Consequently, only lines 2–10 are
different in CheckForTrianglesMapImplementation. Since CheckForTriangles is
generally the faster of the two algorithms, we do not examine CheckForTrianglesMapImplementation in detail but instead refer to [8] for a thorough description of
the algorithm and its implementation.
3.3.2
Time complexity
A detailed worst-case time complexity analysis of the two triangle rigidity detection
algorithms is presented in [8]. The time complexities presented are valid for the
adding of a brick and concern only the triangle rigidity detection algorithms, not
the detection of double connections between the added brick and rigid structures.
In the following, the total number of bricks in the model is n, the number of
rigid structures after the addition of the new brick but before the triangle rigidity
detection is r and the number of rigid structures after the triangle rigidity detection
is r0 . In other words, r0 can have values between 1 (if the whole structure is detected
13
as a single rigid structure) and r (if no structures are detected as rigid relative each
other in the triangle rigidity detection).
The worst-case time complexity for complete triangle detection using CheckForTriangles after the adding of a brick is
O(max(n + r, r2 )(r − r0 )).
The worst-case time complexity for complete triangle detection using CheckForTrianglesMapImplementation after the adding of a brick is
O((n + r)(r − r0 )).
Examples of actual runtimes for the triangle rigidity detection are also presented.
15 different Lego models, available for download from the Lego web site [11], were
tested. They have been built using System bricks (traditional Lego bricks) in the
Digital Designer application, by users or by Lego. The models were chosen as an
attempt to achieve a representative selection; however, emphasis was put on large
models. In practice, this means that most models contained between 100 and 1000
bricks. The largest model contained less than 1100 bricks. Appendix A shows the
complete test data. In Table A.1, the runtimes for rigidity detection for each model
are shown. In Table A.2, the numbers of bricks in each model are shown.
Due to the limited—and thereby perhaps unrepresentative—set of test models,
we do not investigate the algorithm runtimes in detail. Instead, we make a couple
of general remarks concerning the runtime analysis.
The runtimes presented in Table A.1 measure the rigidity detection of a complete
model after it has been loaded and are averages for five runs. Rigidity detection
using triangle detection naturally takes longer than when only double connection
rigidity is detected. The runtimes are of order 1 ms, i.e. no model’s rigidity properties take longer than 10 ms to calculate. Observe that CheckForTriangles is faster
than CheckForTrianglesMapImplementation in all cases but one.
Conclusively, it is therefore probable that the runtimes are reasonably low and
should not force the user to wait a noticeable period of time after a brick has been
added. However, also important are the improvements in rigidity detection that the
algorithms result in—and the improvements that are still waiting to be attained.
In the next section, we therefore examine the limitations of the algorithms.
3.3.3
Limitations
More can be done regarding the rigidity in Lego models. The following are limitations or problems concerning the triangle rigidity detection algorithms.
Rigidity beyond triangles
The rigidity detection algorithms in [8] are incomplete, i.e. in a general structure
they do not detect all rigid structures. This is because rigidity can occur in structures not containing any triangles, and this rigidity is not detected by the algorithms.
14
Figure 3.8. An example of a square grid in which the rigidity cannot be detected
using triangle rigidity algorithms.
a)
b)
Figure 3.9. Two examples of structures in which the triangle rigidity detection
algorithms do not detect the rigidity properties correctly. In (a), the top brick is
rigid relative the large rigid structure to the left. In (b), the top and bottom bricks
are rigid relative each other.
Figure 3.10. An example of a structure that triangle rigidity detection algorithms
cannot detect as rigid, since it contains no triangles.
15
Square grids (an example of which can be seen in Figure 3.8) are discussed as a case
where complete rigidity detection is not achieved. When the algorithms are applied
to actual Lego models, a couple of more cases where the rigidity detection is incomplete are also found. Figure 3.9 shows two cases where some bricks are rigid in
relation to each other. In Figure 3.9(a), the top brick is rigid relative the large rigid
structure to the left, since the brick has two noncoincident connections to the rigid
structure. One connection goes through three other rigid structure, and rigidity is
therefore not detected. In Figure 3.9(b), there are two connections with noncoincident rotational axes between the top and bottom brick. However, both connections
go through other rigid structures, and rigidity is therefore not detected.
There are other examples of structures displaying incomplete rigidity detection
than those described in [8]. Figure 3.10 illustrates this—it shows a structure consisting of two rigid structures (horizontal in the figure) connected by three rigid
structures (close to vertical), out of which one is not parallel to the others. This
structure is rigid, however it does not contain any triangles, so the triangle rigidity
detection algorithms do not detect it as rigid. Therefore, it would be desirable to
find algorithms detecting rigidity that goes beyond combinations of triangle structures, and we explore this area further in Chapter 5.
Physical rotational limitations between structures
Another reason for incomplete rigidity detection is physical rotational limitations
between structures. As mentioned earlier, it seems reasonable to allow this incompleteness in the rigidity detection and let the physics engine handle the physical
rotational limitations. Instead, we focus on rigidity caused by the connection patterns between structures.
Removing bricks
The rules brought up in [8] are applicable when a brick is added to the model.
Another interesting case is when a brick is removed from the model. The removed
brick can be vital for the rigidity of some part of the structure—or of the structure
as a whole—and therefore its rigidity functionality must be analyzed when it is
removed. This issue is not treated further in this thesis; instead, we focus on
methods for computing rigidity for a whole model or when a brick is added.
Brick types
In [8], only System bricks (traditional Lego bricks) are considered—and thereby the
extensive domain of Technics bricks is excluded. The triangle rigidity algorithms
should be applicable to this domain, however not without some adaptations. The
adaptations of the triangle rigidity algorithms for the domain of Technics bricks are
not dealt with thoroughly here; however, we touch on the subject in Section 4.2.1.
16
Relevance of improvements
Finally, we must look at what improvements in the rigidity detection the triangle
algorithms actually achieve. Out of the 15 models which tests are performed on in
[8], the number of rigid structures is decreased using the triangle rigidity algorithms
in only three cases. There are triangles detected in seven models, but in four of the
cases the same rigidity properties are detected using only the pre-existing doubleconnection algorithm. However, this lack of improvement in the rigidity detection
in many models cannot be blamed on the algorithms in [8]. On the contrary, they
improve the detection in the cases where it is possible; the rigidity detection is
complete using only the pre-existing double-connection algorithm in nine of the
models, and in three of the models only physical rotational limitations prohibit
complete rigidity detection using the double-connection algorithm. This leaves only
three models where improvements are possible using triangle rigidity detection, and
in these cases the triangle rigidity detection algorithms improve the detection. A
weakness is that the algorithms increase the runtime of the rigidity detection even
when the number of rigid structures is not decreased. However, in light of how short
the times are despite this increment, this should be a problem of little importance.
The lack of improvement in many models raises the question of how necessary
rigidity detection beyond the double-connection algorithm is. Here, it is important
to remember that the models on which the triangle rigidity detection algorithms
were tested is a limited set—and not necessarily representative of how models in
general are built. The possibilities in the Digital Designer application are only
limited by the mind of the user, and therefore the rigidity detection algorithms
must be prepared for any structures imaginable. Also, the relevance of rigidity
detection algorithms beyond double connections is presumably greater in the context
of Technics bricks. Here, single connections should be more common, due to the
various joint-type bricks available. Also, Technics models are often more aimed
towards dynamic properties than System models. Therefore, the search for further
rigidity detection algorithms is relevant, and the area should be further investigated.
17
Chapter 4
Applying theory
Due to the incompleteness of the algorithms described in the previous chapter, a
more general approach to rigidity detection in virtual Lego models is called for.
Therefore, the aim of this thesis is to explore the possibilities of applying theory
presented in scientific literature to Lego models in order to perform rigidity detection.
In this chapter, two different theoretical areas are presented; framework rigidity
and generic rigidity. For each area, the relevant theory is first presented; then, the
possibilities of and problems with applying that particular area of theory to Lego
models are examined.
1
1(1,4)
6(2,2)
2(4,2)
6
5
2
3
a)
4(2,0)
5(0,0)
3(4,0)
b)
4
1(1,4)
6
1
6(2,2)
c)
5(0,0)
2(4,2)
4(2,0)
³
3(4,0)
4
d)
2
5
3
´
e) p = (1, 4), (4, 2), (4, 0), (2, 0), (0, 0), (2, 2)
Figure 4.1. Example showing two frameworks (in (a) and (c)) with the same mapping p (in (e)), but different underlying graphs (in (b) and (d)). In Figures (a) and
(c), joint coordinates are given within parentheses as (xi , yi ).
18
4.1
Framework rigidity
A bar-and-joint-framework—or simply a framework—consists of rigid bars connected via rotatable joints. A bar connects to two (and only two) joints and
constrains the distance between them by keeping it constant. An example of a
framework can be seen in Figure 4.1(a). For descriptions of the theory in this
section, we have in the main referred to [13], [14] and [15].
The connectivity of a framework can be represented by a graph G = (V, E),
where the n nodes in the set V = {v1 , v2 , . . . , vn } correspond to the joints of the
framework, and the m edges in the set E = {e1 , e2 , . . . , em } correspond to the bars.
The graph of the framework in Figure 4.1(a) is shown in Figure 4.1(b).
To uniquely represent a framework, we need to consider that frameworks sharing the same graph can have different realizations (or configurations), i.e. for different frameworks, the joints represented in the graph can have different positions
in Euclidean space. We let p = {p1 , p2 , . . . , pn } be a mapping of the joints to
d-dimensional Euclidean space (pi = (xi , yi ) in two dimensions). A unique realization of an underlying graph thereby corresponds to a unique mapping p, but
frameworks sharing the same mapping can also be unique through differences in
the underlying graph. For example, the framework in Figure 4.1(c) has the same
mapping (shown in Figure 4.1(e)) as the framework in Figure 4.1(a), but its underlying graph (shown in Figure 4.1(d)) is different. Conclusively, the properties of a
framework are completely represented by the triple (V, E, p).
4.1.1
Rigidity and infinitesimal rigidity
We shall now define rigidity of a framework. Given a framework (V, E, p), let {i, j}
be an edge of (V, E). A deformation of the framework is a continuous parameter
family p(t) = (p1 (t), . . . , pn (t)) with p(0) = p, such that the distance between pi (t)
and pj (t) is fixed if {i, j} ∈ E,
(pi (t) − pj (t)) · (pi (t) − pj (t)) = cij , for all {i, j} ∈ E.
(4.1)
The framework (V, E, p) is said to be rigid if it does not admit a continuous deformation preserving all bar lengths other than the trivial translations and rotations.
This is equivalent to p(t) being geometrically congruent to p for all t near 0, i.e. to
the existence of an isometric transformation of p(t) into p for all t near 0. If the
framework is not rigid, then it is flexible.
Since the system of equations (4.1) is quadratic in two variables, it is generally
very difficult to solve. Therefore, instead of looking directly for deformations, i.e.
trying to find a continuous parameter family p(t) that satisfies equations (4.1),
we look for their first derivatives. When the system of equations (4.1) is derived,
dp/dt = p0 must satisfy
(pi − pj ) · (p0i − p0j ) = 0, for all {i, j} ∈ E.
19
(4.2)
For t = 0, this is a system of m = |E| linear equations with the nd = |V |d unknowns being the coordinates of the p0i . In framework theory, it is assumed that a
framework contains at least d + 1 points and that the points are placed in general
position—in other words, that no three points are collinear, i.e. lie on a straight line.
Under this assumption, there are always d(d + 1)/2 solutions of equations (4.2) corresponding to the derivatives of trivial deformations. In two dimensions, this gives
2(2 + 1)/2 = 3 solutions (two translations and one rotation). In three dimensions,
it gives 3(3 + 1)/2 = 6 solutions (three translations and three rotations). If the system of equations (4.2) has no other solutions, then we call the framework first order
rigid, or infinitesimally rigid. A non-trivial solution to equations (4.2) is called an
infinitesimal flex or just a flex.
Infinitesimal rigidity is a natural approximation to rigidity, and rigidity is only
implied by infinitesimal rigidity under the general position assumption described
above. When all joints of a framework are in general position, we also speak of a
generic realization or a generic configuration. If the joint positions of a framework
are generated randomly, the probability for the configuration of a framework to be
generic is 1. More can be said in mathematical terms about the connection between
rigidity and infinitesimal rigidity (as described in [15]), but for our purpose it is
sufficient to give a less formal description.
If a structure admits a finite flex, then it obviously also admits an infinitesimal
flex. Likewise, if a structure is infinitesimally rigid (i.e., it does not allow for an
infinitesimal flex), then it is also rigid (because no finite flex can be possible without
an infinitesimal flex). However, rigidity is not equivalent to infinitesimal rigidity.
This is illustrated by the triangle in Figure 4.2. Figure 4.2(a) shows a structure
that admits a finite flexing, and is therefore not rigid. In Figure 4.2(b), one bar
is added, which makes the structure both rigid and infinitesimally rigid. However,
there are realizations of the same triangle which are rigid but not infinitesimally
rigid. An example is shown in Figure 4.2(c), in which the three joints are aligned
(note that there is still an edge between joints 1 and 2). The genericity requirement
is thus not satisfied. As a consequence, joint 3 may be displaced by a small amount
in the direction of the normal to bar 12, with all bar lengths remaining unchanged
to first order in the displacement. This is equivalent to the existence of a non-trivial
solution to equation (4.2). Therefore, this structure is infinitesimally flexible but
still rigid.
It is important to note what the actual consequences of infinitesimal flexibility in
rigid structures are. While infinitesimal flexes are not realizable in an ideal motion
of the framework, they certainly give rise to sagging or swaying in any physical
model of bars and joints. A decision must be made about whether these effects
should be taken into account or ignored in the context of virtual Lego models. This
issue is discussed in Section 4.2.2.
20
1
1
1
3
3
a)
3´
3
2 b)
2 c)
2
Figure 4.2. A simple example of why a framework may fail to be infinitesimally
rigid (cases (a) and (c)). The framework in (a) is flexible, since it admits a continuous
deformation. The framework in (b) is both rigid (no continuous deformation possible)
and infinitesimally rigid (no infinitesimal deformation possible). The framework in
(c), on the other hand, is rigid but not infinitesimally rigid, since joint 3 may be
displaced by an infinitesimally small amount, letting all bar lengths remain unchanged
to first order in the displacement.
4.1.2
Computing infinitesimal rigidity
The m equations in (4.2) can be collected into a single one,
Au = 0,
(4.3)
where, if we consider two dimensions, u = (x01 , x02 , . . . , x0n , y10 , y20 , . . . , yn0 )T and A =
akl is an m × 2n matrix—called the rigidity matrix—with


 xi − xj
akl =
yi − yj

 0
if bar k is between joints i and j, and l = i
if bar k is between joints i and j, and l = i + v
otherwise
For example, in the case of the framework in Figure 4.3, we have


x1 − x2 x2 − x1
0
y1 − y2 y2 − y1
0


0
x3 − x1 y1 − y3
0
y3 − y1  .
A =  x1 − x3
0
x2 − x3 x3 − x2
0
y2 − y3 y3 − y2
The matrix can be expanded to three dimensions if we add the corresponding zcoordinate differences to the right of the matrix. In three dimensions, the matrix is
of size m × 3n.
Note that the system of equations (4.3) is linear. Since the joint positions
provide the entries of A, the matrix is real (in a given instant). An intuitive
thought might be that a rigid framework does not allow any motions, and that
u = 0 therefore should be the only solution of the system of equations (4.3). (In two
dimensions, this would give r(A) = 2n.) However, the translations and rotation of
the whole framework provide nontrivial solutions to (4.3), and therefore r(A) < 2n.
These motions of the whole plane can be shown to form a three-dimensional vector
21
1(x,y)
1
3(x,y)
3
1
3
2(x,y)
2
2
Figure 4.3. The example framework for which we create the rigidity matrix.
space [14], and therefore r(A) < 2n − 3. (We always suppose n ≥ 2, i.e. that the
framework consists of at least one bar.) This gives us the following lemma.
Lemma 4.1 If a framework has at least three joints and r(A) < 2n − 3 holds, then
the framework is not rigid.
Proof. Proving the lemma is now trivial. The solutions of Au = 0 form a
subspace of dimension at least 4. Were the framework rigid, then every motion
of it would be composed of translations and a rotation, but in this way at most
dimension 3 could be obtained. 2
Thus, rigidity for two-dimensional frameworks can be defined in the following
manner.
Definition 4.1 (2D framework rigidity) A two-dimensional framework is rigid
if r(A) = 2v − 3 holds for its rigidity matrix A.
If a framework is nonrigid, the nontrivial solutions of the system of equations (4.3)
determine the motions beyond translations and a rotation of the framework. The
nontrivial motions can be true flexes of the framework or “infinitesimal motions”
(like the one shown in Figure 4.2).
The argument can easily be expanded to three-dimensional frameworks, yielding
the following definition for rigidity.
Definition 4.2 (3D framework rigidity) A three-dimensional framework is rigid
if r(A) = 3v − 6 holds for its rigidity matrix A.
Here, six trivial motions (three translations and three rotations) are possible.
Relating to the area of generic rigidity, which we examine in Section 4.3, we
can make another observation. Since A has m rows, obviously r(A) ≤ m. Thus,
if a framework is rigid in two dimensions, then m ≥ 2n − 3 holds. Similarly, for
a framework which is rigid in three dimensions, m ≥ 3n − 6. The conditions are
necessary but not sufficient. In Section 4.3, we further explore the sufficiency side
of rigidity. First, however, we look at how well framework rigidity theory can be
applied to virtual Lego models.
22
4.2
Applying framework rigidity
We now want to use the theory from the previous section to compute the rigidity
properties of Lego models. When applying the theory to Lego models, we face
several obstacles. In this section, these obstacles are discussed, and solutions are
presented for some of them. As explained in the introduction of this thesis, we shall
focus on two-dimensional models. Results are only valid for three dimensions when
explicitly stated.
4.2.1
Representing Lego models
When representing a Lego model as a framework, we face two major problems;
exactly what parts of a Lego model should the bars and joints of a framework
represent, and how do we overcome the fact that bars in a framework are always
connected to other bars via precisely two joints? We first look at the bar and joint
representation problem.
Bar and joint representation
An intuitive thought might be to let each Lego brick be represented by a bar in the
representing framework. However, since the detection of double (or higher-order)
connections between bricks is efficient, it would probably be wiser to let instances
of the class PrimitiveRigidElement be represented by bars in the framework.
Thereby, the number of bars would decrease significantly, and since PrimitiveRigidElements have the same rigidity properties as rigid bars, the simplification
would cause no problems.
Another possibility would be to let instances of the class RigidElement be represented by bars. That would decrease the number of bars even further if triangles
exist in the model. Whether this would be a preferred method or not depends on
whether the rigidity matrix computation for the framework could replace the triangle rigidity detection algorithms. Subsequently, we shall informally refer to the
objects in a Lego model represented by bars as rigid structures.
When dealing with System bricks, the nonrigid connections between rigid structures can obviously be represented as joints. However, when Technics bricks are
taken into account, the scenario is more complex. This is due to the existence of
joint bricks, i.e. bricks that function as rotational axes when connected to two (or
more) rigid structures. In Figure 4.4, a few different joint bricks are shown.
When adding the domain of Technics bricks to the Digital Designer application,
one should also add information about which bricks that can function as joints.
When a joint brick is connected to its first rigid structure, the brick and the structure
can be considered rigid relative each other. However, when a second (or higherorder) rigid structure is connected to the joint brick, they must remain flexible
relative each other—otherwise all rigid structures connected to the joint brick would
become rigid relative each other.
23
Figure 4.4. A few examples of different kinds of joint bricks.
Two-joint bar connection
As stated in the previous section, each bar in a framework is always connected to
precisely two joints. Rigid structures in a Lego model, however, can be connected
to other rigid structures with only one joint—or several.
If a rigid structure has only one joint connection, then it is nonrigid relative the
structure on the other side of that connection. A framework bar must always have
two joint connections, so every time we add a brick we must check if it has only
one connection to other structures. If that is the case, a “dummy connection” must
be added to the rigid structure that the brick constitutes, placed in an arbitrary
position. The dummy connection makes sure that the bar in the framework representation gets two joints as well and thereby follows the rules for a framework.
When the rigid structure receives a second actual joint connection, the dummy
connection position and other information must be changed to that of the added
joint.
More complex is the case where a rigid structure has three or more joint connections. Since a framework bar can only be connected to two joints, the structure
must be converted to a series of triangles, which maintain the rigidity properties
of the structure. Before a new joint is added, we know that the existing structure
is rigid, and thereby its framework representation is rigid as well. Thus, we can
simply add a new joint to the framework representation and connect it with two
bars connected to two distinct—but arbitrary—joints of the rigid structure. That
adds a new triangle to the framework graph of the structure, which maintains its
rigidity.
Conclusively, there seems to be no limitations when it comes to representing
Lego models as frameworks. As long as all joints are one-dimensional (i.e. have
one-dimensional rotational axes), the methods used here should be valid for threedimensional models as well.
24
4.2.2
Implications of infinitesimal rigidity
To examine the consequences of computing the infinitesimal rigidity instead of the
rigidity of a structure, we look at different realizations of prism structures, which
we shall define as follows.
Definition 4.3 (Prism structure) A prism structure is a structure consisting of
two rigid structures A and B and a set C of three or more rigid structures, where
both A and B have connections to all rigid structures in C.
Two three-brick triangles joint-connected via three other bricks (all structures
shown in Figures 4.5(a)–4.9(a) are of this kind) form an intuitive prism structure
(hence the name), but note that two bricks joint-connected via three other bricks
(as shown in Figure 3.10) also qualify as a prism structure by our definition. This
can be defended by the fact that the framework representation of that structure has
the same underlying graph as the representations of the ordinary prism structures.
We have looked at five realizations of prism structures, all displaying different
aspects of rigidity.
• Figure 4.5(a) shows prism 1, where the three vertical bricks are parallel, of
equal length and “vertically aligned”, i.e. the y-coordinates of their joint positions are the same.
• Figure 4.6(a) shows prism 2, where the three vertical bricks are parallel, of
equal length, but not vertically aligned.
• Figure 4.7(a) shows prism 3, where the three vertical bricks are parallel, but
not of equal length and not vertically aligned.
• Figure 4.8(a) shows prism 4, where the “vertical” bricks are not parallel, not
of equal length, but vertically aligned.
• Figure 4.9(a) shows prism 5, where the “vertical” bricks are not parallel, not
of equal length and not vertically aligned.
In Figures 4.5(b)–4.9(b), the corresponding frameworks of the prism structures are
shown.
The rigidity matrix ranks of the prisms were computed by a program written
in Matlab. The program is shown in Appendix B. Table 4.1 shows the vertical bar
properties, the actual rigidity properties, the rigidity matrix rank and the computed
rigidity properties of each prism.
Prism 1 is obviously nonrigid, since the three vertical bricks can move in three
circular motions with the same radius, staying parallel throughout the circles. This
is correctly computed via the rigidity matrix rank.
Prism 2 is also nonrigid, since the vertical bricks still stay parallel in three
circular motions with the same radius. Again, the rigidity matrix rank gives the
correct result.
25
a)
4(0,6)
6(3,6)
5(4,6)
b) 1(0,0)
3(3,0)
2(4,0)
Figure 4.5. Prism 1. The vertical bricks are parallel, of equal length, and vertically
aligned.
6(3,7)
4(0,6)
5(4,6)
3(3,1)
b) 1(0,0)
a)
2(4,0)
Figure 4.6. Prism 2. The vertical bricks are parallel and of equal length but not
vertically aligned.
4(0,6)
5(4,6)
6(3,5)
3(3,1)
b) 1(0,0)
a)
2(4,0)
Figure 4.7. Prism 3. The vertical bricks are parallel but not of equal length or
vertically aligned.
26
4(0,6)
b) 1(0,0)
a)
6(1,6)
5(4,6)
3(3,0)
2(4,0)
Figure 4.8. Prism 4. The vertical bricks are not parallel and not of equal length
but vertically aligned.
4(0,6)
5(4,6)
6(1,5)
3(3,1)
b) 1(0,0)
a)
2(4,0)
Figure 4.9. Prism 5. The vertical bricks are not parallel, not of equal length, and
not vertically aligned.
Prism 3 is more problematic. Here, the flexibility is not obvious, but the framework can assume different realizations through continuous motions. The framework
does not flex back to its original realization when there are no forces affecting it—
hence, it is nonrigid. Intuitively, this might be surprising, since the vertical bricks
move in circular motions with different radii; however, the small flexes are possible
because the vertical bricks are parallel and the initial directions of their motion vectors equal. In other words, prism 3 is rigid but infinitesimally flexible. The rigidity
matrix rank suggests a nonrigid structure, which is consequently correct.
Prism 4 is similar to prism 3. Once again, an intuitive thought might be that
the structure is rigid, suggested by the nonparallel “vertical” bricks; this is true,
however due to the vertical alignment of the upper and lower joints respectively, the
structure can make small but permanent flexes. As with prism 4, prism 3 is rigid
but infinitesimally flexible. The rigidity matrix rank suggests a nonrigid structure,
which is correct.
27
Table 4.1. The rigidity properties of the five discussed prism structures.
Prism
1
2
3
4
5
Vertical bar
properties
Parallel,
of equal length,
vertically aligned
Parallel,
of equal length,
not vertically aligned
Parallel,
not of equal length,
not vertically aligned
Not parallel,
not of equal length,
vertically aligned
Not parallel,
not of equal length,
not vertically aligned
Actual
rigidity
properties
Rigidity
matrix rank
Computed
rigidity
properties
Nonrigid
7 < 2v − 3
Nonrigid
Nonrigid
8 < 2v − 3
Nonrigid
8 < 2v − 3
Nonrigid
7 < 2v − 3
Nonrigid
9 = 2v − 3
Rigid
Infinitesimally
nonrigid
Infinitesimally
nonrigid
Rigid
Prism 5 is the only prism of the ones examined here that is unquestionably rigid.
This is due to the “vertical” bricks not being parallel, of equal length or vertically
aligned. This is the only case where the rigidity matrix rank computation suggests
rigidity, and that result is correct.
The computed rigidity properties for prisms 3 and 4 are in reality correct; however, that is not to say that they follow the previous definitions for rigidity used
for virtual Lego models in the Digital Designer application. If we for example look
at prism 4, the top and bottom triangles have no coincident rotational axes, and
would thus be detected as rigid. This would prohibit any infinitesimal flexes, and
thereby the whole prism structure would be rigid. Accordingly, we would like to
detect prism 3 as rigid as well. We therefore want a rigidity detection method that
ignores infinitesimal flexibility, and the rigidity matrix rank computation does not
fulfil this requirement.
Even though this is an admissible flaw—rigid structures that are considered
flexible are still taken care of by the physics engine—it is severe enough to act
as a negative for the rigidity matrix rank method. Moreover, we shall see in the
following two sections that the matrix rank method faces bigger obstacles than that
of infinitesimal rigidity.
28
4.2.3
Rigidity matrix size
A possible drawback of the rigidity matrix representation is the size of the matrix
A. As the Lego model grows larger, the matrix might become unwieldy.
The rank of a matrix can be computed in several different ways; Matlab, for
example, uses an algorithm based on singular value decomposition [12]. However, I
have not been able to find information on time complexity of matrix rank calculation. Consequently, we can not draw any precise conclusions as to how the algorithm
scales. We therefore settle with an approximate time estimate of the matrix rank
calculation for a large model.
To estimate the size of a large rigidity matrix, we must make some assumptions.
The largest models described in [8] has approximately 100 rigid structures. First,
let us make optimistic assumptions. If we assume that each rigid structure has only
two joint connections, then m = 100. Estimating n is more difficult. The value
of n depends on how many rigid structures that are connected to each joint; the
more rigid structures that are connected to each joint, the lower the value of n is.
Many joints are probably connections between just two rigid structures, so it would
probably be optimistic to assume that each joint connects to three rigid structures.
This gives n = 23 · 100 ≈ 67, and an approximate matrix size of m × 2n = 100 × 133.
Computing the rank of a matrix of this size should pose no problems, but we now
look at what happens if the estimates are not as optimistic.
If we keep the number of rigid structures at 100 and assume that each rigid
structure instead has on average 4 joint connections, then the number of bars in the
framework representation is quite large. Each rigid structure is then represented by
two triangles consisting of 5 bars, which gives m = 500. Since joint connections are
only interesting if they connect to other rigid structures, each joint in the framework
must now connect to at least three bars. We keep making pessimistic estimates,
and let n = 23 · 500 ≈ 333. This gives an approximate matrix size of m × 2n =
500 × 667, and computing the rank of this matrix can be cumbersome; it takes
Matlab approximately a second to compute the rank of a randomly generated matrix
of this size—a time that is not acceptable in the Digital Designer application.
One might object that the rigidity matrix is enlarged successively and is therefore
not as time-consuming to calculate the rank of (since computing the rank involves
reducing the matrix to echelon form). Unfortunately, it has been beyond the scope
of this thesis to investigate this issue further. More importantly, as we shall see
in the next section, there is a more serious problem with the rigidity matrix rank
computation than the matrix size.
4.2.4
Detecting rigid structures
The aim of this thesis has been to relieve the physics engine of the Digital Designer
application by detecting rigid structures in Lego models. Therefore, the most important subject in relation to framework rigidity is how the theory can be used to
detect rigid structures.
29
Unfortunately, no progress has been made when it comes to framework theory
and rigid structures in Lego models in this project. It is inherent in the matrix rank
method that it calculates whether a whole framework is rigid or not—not which
parts of the framework that are rigid—and this property is not a good foundation
for solving our task.
A naive approach would be to compute the rigidity for all possible subframeworks, and thereby decide which structures of the Lego model that are rigid. However, as the number of subframeworks is exponential in n, this method would soon
become fruitless as n grows large.
4.2.5
Conclusion
We have seen that Lego models could probably be modeled as frameworks without
any serious loss of information. However, a number of obstacles seem quite difficult
to overcome; the rigidity calculations may in reality be correct, but not sufficient in
the context of virtual Lego models; the size of the rigidity matrix may slow down the
calculations more than is reasonable; and most importantly, there is no apparent
way of detecting rigid substructures using the theory.
All this calls for the examination of another theoretical area. In the next section,
we look at a method that might be more useful when it comes to detecting rigid
structures.
4.3
Generic rigidity
Generic rigidity, also called structural rigidity or graph rigidity, is a purely combinatorial matter. Here, we let the underlying graph G = (V, E) of a framework
hold all of the relevant information; in other words, the coordinates of the joints
are arbitrary. All that is taken into account is which joints (nodes) are connected
by bars (edges), i.e. which pairs of nodes that have a constant internal distance.
It should be noted that the distances between nodes remain unspecified in the case
of generic rigidity and can be given any value as long as they are constant. If two
nodes have a constant internal distance—directly, due to an edge between them, or
indirectly, due to edges between other nodes—we also speak of a constraint on the
nodes.
In this section, we first explain generic rigidity in the plane thoroughly. Then,
we give a brief insight into the research area of three-dimensional generic rigidity.
4.3.1
Generic rigidity in two dimensions
When considering graphs in the plane, we need to define what we mean by a rigid
graph. We shall now give an informal definition. Given a graph G = (V, E), where
the edges in E determine which pairs of nodes in V must have a constant distance
between them, we say that a graph is rigid if all nodes in the graph are constrained
to have relative constant distances between them. In other words, in a rigid graph,
30
a)
b)
Figure 4.10. Example of how two graphs with the same number of nodes can have
different rigidity properties. While the graph in (a) is rigid, the upper square in the
graph in (b) can flex sideways. This is due to the graph in (b) having a redundant
edge, marked here by a thicker line.
no nodes can “move” relative each other. An obvious case where this occurs is
when all pairs of nodes are constrained by edges; however, as we shall see, this
requirement is far from necessary to achieve rigidity.
What are the requirements for a graph to be rigid? Obviously, the more edges
that constrain the movements of the nodes, the more likely the graph is to be rigid.
However, the number of edges is not sufficient to determine the rigidity properties
of a graph; one must also consider whether or not the edges are appropriately
distributed. Figure 4.10 shows a simple example of how two graphs with the same
number of nodes and edges can have different rigidity properties. While the graph
in Figure 4.10(a) is rigid, the graph in Figure 4.10(b) is not. This is because one of
the edges (the thick one) in the second graph does not add a new constraint to the
set of nodes, and therefore does not contribute to making the graph more rigid.
To further explain what is meant by “appropriately distributed” we need to
introduce the concept of independence among edges in a graph. An edge is independent of the other edges in a graph if it adds a constraint to the nodes which
does not already exist on account of the other edges. (Obviously, the previously
mentioned edge in Figure 4.10(b) does not satisfy this requirement.) Thus, the
detection of rigidity comes down to a counting of independent edges in the graph.
In the next section, this concept is presented in a more formal manner.
Laman’s theorem
The first graph theoretic characterization of rigid graphs in two dimensions was
given by Laman [9].
Theorem 4.2 (Laman) The edges of a graph G = (V, E) are independent in two
dimensions if and only if no subgraph G0 = (V 0 , E 0 ) has more than 2n0 − 3 edges.
Corollary 4.3 (2D Generic rigidity) A graph with 2n − 3 edges is rigid in two
dimensions if and only if no subgraph G0 has more than 2n0 − 3 edges.
31
Figure 4.11. The example graph through which the pebble game algorithm is
visualized in this thesis.
Laman’s theorem can be visualized in an intuitive manner. In two dimensions,
a set of n nodes has 2n possible independent motions, but the three rigid body
movements (two translational and one rotational movement) cannot be constrained.
If each edge adds an independent constraint, then 2n − 3 edges are required to
eliminate all nonrigid motions of the graph. If any subgraph with n0 nodes has
more than 2n0 − 3 edges, then those edges cannot be independent [5].
If an edge is not independent in relation to some other set of edges, we call that
edge redundant in relation to that set. We note that a graph with less than 2n − 3
edges cannot be rigid, since it does not have enough edges to constrain all the nontrivial motions of its nodes. Moreover, to decide whether a graph with more than
2n − 3 edges is rigid, we conclude that one first has to remove all redundant edges
(by examining their independency), then see if the graph has 2n − 3 independent
edges; if so, it is rigid.
Laman’s theorem lets us determine the rigidity of a plane graph by counting
the number of edges in every subgraph. However, in its original form it results in
a poor algorithm, since the number of subgraphs is exponential. More importantly,
the theorem has laid the foundations for many algorithms for detecting generic
rigidity. A description of the development within this field is given in [1]. We
now look closer at one of the algorithms based on Laman’s theorem that count
independent edges in polynomial time.
32
Pebble game algorithm
The pebble game algorithm takes as parameter a graph G = (V, E) and gives a
maximum set of independent edges. For this purpose, we let G be a multi-graph,
i.e. we let G have 0, 1 or several edges between two nodes. The pebble game
algorithm is presented in [5], and all information in the following sections regarding
it comes from that source unless otherwise stated.
We take as example the graph in Figure 4.11 and show how the pebble game
algorithm deals with it. The starting point of the algorithm is the following formulation of Laman’s theorem.
Theorem 4.4 For a graph G = (V, E) having m edges and n nodes, the following
are equivalent.
A. The edges of G are independent in two dimensions.
B. For each edge (a, b) in G, the graph formed by adding three additional edges
(a, b) has no induced subgraph G0 in which m0 > 2n0 .
Here, an induced subgraph is simply the graph consisting of some subset of nodes
together with all the edges that have both endpoints in the subset of nodes.
Condition A of Theorem 4.4 is equivalent to the first part of Laman’s theorem
as it is formulated in Theorem 4.2. Condition B is derived from the second part of
Theorem 4.2; if no subgraph has more than 2n0 − 3 edges, then adding three copies
of any edge can never give a subgraph with more than 2n0 edges.
The algorithm grows a maximal set of independent edges one at a time. This set
of basis edges is denoted by Ê. A new edge is added to the basis if it is independent
of the current set. If 2n − 3 independent edges are found, then the graph is rigid.
The efficiency of the algorithm lies in the determination of whether or not a new
edge is independent of the existing basis.
Assume that we have a (possibly empty) set of independent edges Ê. Combined
with the nodes of G these edges form a graph Ĝ. The number of edges in Ĝ is O(n),
since there are at the most 2n edges in the basis. We wish to determine if another
edge, e, is independent of Ê. Adding e to Ĝ produces Ḡ. By Theorem 4.4, e is
independent of Ê if and only if there is no subgraph with too many edges (m0 > 2n0 )
after any edge in Ḡ is quadrupled, i.e. after three additional edges between the same
pair of nodes have been added. Actually, only e needs to be quadrupled, as the
following lemma demonstrates.
Lemma 4.5 A new edge e is independent of Ê if and only if the graph G4e , formed
by quadrupling e, has no induced subgraph G0 in which m0 > 2n0 .
Proof. It follows directly from Theorem 4.4 that the condition is sufficient. To
show that it is necessary, assume the opposite. Suppose that no subgraph of G4e
has too many edges when e is quadrupled, but e is not independent of Ê. Then,
by Theorem 4.4, there must exist some edge in Ê whose quadrupling leads to G0 ,
33
Figure 4.12. Our example graph after the bottom row of edges have been added.
Small filled circles denote nodes. Large (filled, open) circles denote (covering, free)
pebbles.
a subgraph of Ḡ, having m0 > 2n0 . Since the edges of Ê are independent, this bad
subgraph must include e. But the bad subgraph has the same number of edges it
had within G4e , which leads to a contradiction. 2
Lemma 4.5 reduces the complexity of independence testing to that of counting
edges in subgraphs once the new edge is quadrupled. This is done using the following
pebble game.
• Each node is given two pebbles.
• The pebbles at a node can be used to cover any two edges which are incident
to that node.
• The aim is to assign the pebbles in such a way that all the edges in the graph
are covered. Such an assignment is called a pebble covering.
It is shown below that the existence of a pebble covering is equivalent to there
being no induced subgraph of n0 nodes with more than 2n0 edges—the independence
condition in Lemma 4.5. First, we must describe how the pebbles should be moved
around to cover a new edge.
Given a set of edges that are covered with pebbles, we want to add a new edge
and rearrange the pebbles to cover it. First, we examine if either of the nodes
incident to the new edge has a free pebble. If that is the case, then that pebble is
used to cover the new edge and the algorithm continues to the next edge. Otherwise,
34
4
4
3
3
3
3
4
4
1
1
a)
0
2
2
4
2
2
4
3
1
5
3
b)
0
2
3
3
Figure 4.13. A portion of a directed graph in our example graph as determined
by the pebble covering The (filled, open) circles denote (covering, free) pebbles. A
pebble search follows along the arrows. The numbers on the nodes is the minimum
search length from the starting node. For example, the node with number 0 is the
starting node and the number 3 on a node indicates that it can be reached in three
steps. Figure (a) shows a breadth-first search for a free pebble. In Figure (b), the
pebbles have been rearranged, and a second pebble search is made.
all four pebbles belonging to the incident nodes has been used to cover existing
edges. If a node at the other end of one of those edges has a free pebble, then that
pebble can be used to cover the existing edge, which makes a pebble available to
cover the new edge. Figure 4.12 shows our example graph after the bottom row of
edges has been added and covered with pebbles.
In formal terms, the search for free pebbles occurs in a directed graph, where
an edge eab covered by a pebble from node a is directed from a to b. From each
node v, we search along the (at the most two) edges directed away from v. The
search continues until either a pebble is found and the new edge is covered through
a sequence of swaps, or until no more nodes can be reached and no free pebbles
have been discovered. The directed graphs for the pebble searches for one of the
edges in our example graph are shown in Figure 4.13.
The pebble game algorithm is shown in Figure 4.14. By calling Enlarge_Cover
four times, once for each copy of the new edge, we can determine whether a pebble
covering exists for G4e . If Enlarge_Cover fails, then all the pebbles belonging to
the nodes that are visited in the search are already covering edges. An example
of such a failed search is shown in Figure 4.15. If n0 nodes are visited, then they
must have at least 2n0 induced edges to consume all their pebbles. This observation
allows us to prove that pebble coverings are equivalent to edge independence, but
35
01 Algorithm EnlargeCover(G, eab )
02
For Each vertex v
03
seen(v) = False
04
path(v) = −1
05
found = FindPebble(G, a, seen, path)
06
If (found)
07
RearrangePebbles(G, a, seen)
08
Return (Success)
09
If (Not seen(b))
10
found = FindPebble(G, b, seen, path)
11
If (found)
12
RearrangePebbles(G, b, path)
13
Return (Success)
14
Return (Failure)
15 Function FindPebble(G, v, seen, path)
16
seen(v) = True
17
path(v) = −1
18
If (v has free pebble)
19
Return (True)
20
Else
21
x = neighbour along edge my pebble covers
22
If (Not seen(x))
23
path(v) = x
24
found = FindPebble(G, x, seen, path)
25
If (found)
26
Return (True)
27
y = neighbour along edge my other pebble covers
28
If (Not seen(y))
29
path(v) = y
30
found = FindPebble(G, y, seen, path)
31
If (found)
32
Return (True)
33
Return (False)
34 Subroutine RearrangePebbles(G, v, path)
35
While (path(v) 6= −1)
36
w = path(v)
37
If (path(w) = −1)
38
Cover edge (v, w) with free pebble from w
39
Else
40
Cover edge (v, w) with pebble from edge (w, path(w))
41
v=w
Figure 4.14. Algorithm for enlarging a pebble covering.
36
testedge
Figure 4.15. A failed search (in thick lines) across a test edge in our example
graph leads to a set of closed paths as indicated by the arrows. Dashed lines denote
uncovered redundant edges.
we first need the following two lemmas.
Lemma 4.6 If the new edge, e, is tripled instead of quadrupled to form G3e , then
G3e has a pebble covering.
Proof. Assume the contrary. Then there is some induced subgraph G0 of G3e
with m0 > 2n0 . Remove three copies of e from this subgraph and quadruple one of
the other edges already present. This altered subgraph still has m0 > 2n0 , but it is
the graph generated by quadrupling an edge in Ĝ. However, since the edges of Ĝ
are assumed to be independent this is a contradiction. 2
Lemma 4.7 If G4e , the graph constructed by quadrupling e, does not have a pebble
covering, then the set of n0 nodes visited in Find_Pebble already have 2n0 induced
edges.
Proof. By Lemma 4.6, when e is quadrupled, the first three copies of it can be
covered. Since all the pebbles among the n0 nodes are now in use, 2n0 ≤ m0 + 3.
Since the m0 edges are independent, we must have equality. 2
In order to determine that a new edge is not independent of the existing basis,
the algorithm identifies a subgraph on n0 nodes that already contains 2n0 − 3 edges.
If no such subgraph is found, the algorithm successfully enlarges the covering. This
leads to the following theorem.
37
Theorem 4.8 A new edge e is independent of Ê if and only if there exists a pebble
covering when e is quadrupled.
Proof. Assume that a pebble covering exists. No subgraph on n0 nodes can have
more than 2n0 induced edges since this is the total number of pebbles available to
those nodes. When combined with Lemma 4.5, this completes the “if” portion of
the proof.
For the “only if” proof, assume that e is independent, but no pebble covering
exists. Algorithm Enlarge_Cover either enlarges a covering or identifies a subgraph
on n0 nodes with more than 2n0 edges. If no such subgraph exists, the algorithm
finds a pebble covering. 2
The pebble game lends itself to a physical analogue. The pebbles assigned to
each node represent the degrees of freedom of that node. A node with one free pebble
has one independent motion. A node with two free pebbles has two translational
motions and can move freely in the plane. If another node has two free pebbles, then
the distance between this pair of nodes is not constant. An edge placed between
the nodes is an independent constraint since the internal distance is set to the edge
length. One of the four free pebbles covers the edge and marks it as an independent
constraint. Once an edge is covered by a pebble, it must remain covered (although
possibly by a sequence of different pebbles) throughout the rearrangement of the
pebbles. The constraints in the movement of pebbles results in the property that a
rigid cluster of two or more nodes cannot have more than three free pebbles. The
three free pebbles physically correspond to the three degrees of freedom required to
determine the position of a rigid body in two dimensions.
The pebble game algorithm has been implemented and is available as an interactive Java applet [4]. Trying out the applet is an effective means of understanding
how the algorithm in general, and the search for pebbles in particular, works.
Time complexity
The time to perform an enlargement by checking a new edge for independence and
potentially adding it to Ê is linear in the number of nodes. The initialization is
linear, and the recursive calls to Find_Pebble perform a search in the graph of
covered edges, which has at most 2n edges. Consequently, we have the following
corollary.
Corollary 4.9 If Ê is independent and a corresponding pebble covering Ĝ is known,
then determining whether a new edge is independent requires O(n) time.
Proof. By Lemma 4.5, testing for independence of e requires just enlarging the
covering in Ĝ to include the four copies of e. This requires four invocations of the
Enlarge_Cover algorithm. 2
This gives a structural rigidity-testing algorithm in two dimensions that runs
in worst-case time O(nm). The algorithm builds a maximal set of independent
38
edges one at a time by testing each edge for independence. Each test involves the
enlargement of a pebble covering requiring O(n) time. If the covering succeeds, the
edge is independent and is added to the basis; otherwise it is discarded.
Detecting rigid clusters
Described in [5] is a method for decomposing graphs into rigid clusters, i.e. sets of
edges which in each set are rigid relative each other. An edge can only belong to
one rigid cluster, so each edge is assigned a cluster label. A set of edges having
the same label defines a rigid cluster. A node belonging to two or more rigid
clusters is identified as a pivot. The following method identifies rigid clusters using
Find_Pebble and Rearrange_Pebbles.
Isolated nodes are identified first as rigid clusters. To identify the remaining
clusters:
1. Introduce a new cluster label for an unlabeled edge.
2. Gather three pebbles at its two incident nodes.
3. Temporarily pin the three free pebbles down and mark the two incident nodes
as rigid.
4. Using a neighbour table, check the unmarked nearest neighbours to the set
of rigid nodes. For each new unmarked node, perform a pebble search and
attempt to free a pebble.
5. If a free pebble is found, the node is not mutually rigid with respect to the
initial edge nor is any other node that was encountered during a pebble rearrangement. Mark all these nodes floppy.
6. If a free pebble is not found, the node is mutually rigid with respect to the
initial bond as well as all other nodes that make up the failed search. Mark
these nodes as rigid and include them in the set of rigid nodes.
7. Return to Step 4 until all nearest neighbours to the set of rigid nodes have
been marked floppy.
8. All edges between pairs of nodes marked rigid are given the same cluster label.
9. Remove floppy and rigid marks from all nodes. Return to Step 1 until no
unlabeled edges remain.
Here, we do not go further than to simply present the rigid cluster detection
method in this list. The reason for this is that the practical use of generic rigidity for
our purpose at this point seems limited, as we shall see in Section 4.4. The resulting
rigidity properties that are given by the pebble game algorithm when applied to our
example graph are shown in Figure 4.16.
Next, we briefly discuss the results achieved in the context of three-dimensional
generic rigidity.
39
Figure 4.16. The rigidity properties of our example graph as detected by the pebble
game algorithm. Shaded regions highlight rigid clusters with more than one edge. A
filled circle denotes a node that is a member of only one cluster. Open circles denote
pivots. Thick solid and dashed lines denote overconstrained edges. A dashed line
indicates a redundant edge.
4.3.2
Generic rigidity in three dimensions
The generalization of Laman’s theorem to general three-dimensional graphs is not
valid. Nevertheless, several results have been achieved in the research on threedimensional generic rigidity. Most of these results have been reached in the study of
rigidity in glasses, where molecular graphs are used to model atom-bond networks
with bond-angle forces. In a molecular graph, nodes represent atoms and edges
represent the covalent forces that define bond length between pairs of atoms. Also,
for each edge-pair sharing a common node, an additional edge is added to represent
bond-angle forces.
Franzblau presented algorithms for computing both non-trivial lower and upper
bounds on the number of degrees of freedom of a graph in three dimensions [1, 2] and
stated that even though the results are reached in a discussion of molecular graphs,
they can be generalized to standard graphs in three dimensions [2]. Jacobs proposed
that Laman’s theorem generalizes to three dimensions for bar-joint networks that
have no implied-hinge joints, i.e. joints that are formed when two rigid clusters
share only two nodes v1 and v2 without a common edge connecting (v1 , v2 ) [3].
An example of an implied-hinge joint—a so called “banana graph”—is shown in
Figure 4.17.
The potential of the research on three-dimensional generic rigidity in the context
of Lego models is further discussed in Section 4.4.
40
Figure 4.17. Three-dimensional banana graph.
4.4
Applying generic rigidity
Now that we have described the generic rigidity theory, we look at how well the
theory can be used to solve our rigidity problem. As with framework rigidity, several
obstacles arise when we want to apply generic rigidity theory to Lego models.
4.4.1
Representing Lego models
When representing a Lego model as a graph, we face the same problems as when
representing it as a bar-and-joint-framework; what parts of the model should the
edges and nodes of the graph represent, and how do we overcome the fact that edges
in a graph are always connected to other edges via precisely two nodes, while Lego
bricks can have several joint connections to other bricks? We first look at the edge
and node representation problem.
Edge and node representation
The representation of Lego models as graphs can be solved in a similar manner
as the representation as frameworks; in this case, we can let instances of the class
PrimitiveRigidElement or of the class RigidElement be represented by edges.
Subsequently, we shall informally refer to the objects in a Lego model represented
by bars as rigid structures.
As with the joints in a framework, we let the nodes in the graph represent
nonrigid connections between rigid structures. When adding the domain of Technics
bricks to the Digital Designer application, we would also represent joint bricks as
nodes.
Two-node edge connection
As with the bars in a framework, edges in a graph are always connected to precisely
two nodes. Rigid structures, on the other hand, can be connected to other rigid
structures with only one joint—or infinitely many. This problem can be dealt with
in the same way as for frameworks.
41
Figure 4.18. The underlying graph of all the prism structure discussed in this thesis.
If a rigid structure has only one joint connection, then it is nonrigid relative
the structure on the other side of that connection. As described in Section 4.2.1,
we must add a “dummy connection” to the rigid structure, and let the edge in the
graph connect to two nodes. When the rigid structure receives a second actual joint
connection, the dummy connection position and other information must be changed
to that of the added joint.
If a rigid structure has three or more joint connections, it must—as in the
case with framework representation—be converted to a series of triangles, which
maintain the rigidity properties of the structure. When a new joint is added to the
rigid structure, we connect a new node to two distinct but arbitrary nodes of the
rigid structure. The new triangle then maintains the rigidity properties of the rigid
structure. This process corresponds to the case with framework representation.
Conclusively, graph representations of Lego models are indeed possible; however,
as we shall see in the next section, loss of crucial information occurs when we ignore
the coordinates of the joint connections in the models.
4.4.2
Loss of geometric information
When we calculated the rigidity properties using the rigidity matrix in Section 4.2.2,
the number of structures that were considered rigid was lower than what reality
showed. When we use the pebble game algorithm, based on Laman’s theorem, the
opposite occurs.
As an example, we look at the prism structures in Figures 4.5(a)–4.9(a). We
are only interested in the underlying graphs of the structures, which—since the
Euclidean coordinates are ignored—all amount to the same graph (shown in Figure 4.18). In this graph, no subgraph has more than 2n0 − 3 edges, and the edges
are therefore independent. Since the graph has 2n − 3 edges in total, it is by Corollary 4.3 rigid. I have verified this result using the Java applet implementation of
the pebble game algorithm mentioned in Section 4.3.1.
No matter which decision we make about the rigidity of prisms 3 and 4, the
calculation of prisms 1 and 2 as rigid is definitely incorrect. These prisms can
flex because their vertical bars are parallel and of equal length; however, as this
42
realization occurs with a probability of 0 if the joints are placed arbitrary in the
plane, it is seen as singular and is therefore not taken into account by Laman’s
theorem.
The consequence of this is that structures that are not rigid are considered rigid
by the pebble game algorithm, a consequence which is not allowed in the Digital
Designer application. This is the most serious flaw in the application of generic
rigidity theory to Lego models.
4.4.3
Generic rigidity in three dimensions
As we saw in Section 4.3.2, Laman’s theorem does not generalize to three dimensions. Therefore, there is no pebble game algorithm to apply on general threedimensional Lego models.
It is possible that Lego models form a subset of general three-dimensional structures that is possible to adapt the pebble game algorithm for. Also, one might be
able to come up with an algorithm that decomposes a three-dimensional structure
into plane structures, for which the rigidity properties can be computed individually. Possibly, the planes could then be merged to determine the rigidity properties
for the whole structure.
Unfortunately, no results have been reached in relation to these suggestions.
Also, the generalization to three dimensions would not solve the erroneous rigidity
calculations described in the previous section.
4.4.4
Conclusion
Although the pure representation problems are solvable in the context of representing virtual Lego models as graphs, two other obstacles seem quite difficult to
overcome; the loss of geometric information results in a rigidity detection algorithm
that is too inclusive, and at this point, the algorithm is only available for general
structures in two dimensions.
Because of these problems, we are forced to turn to heuristic measures. In the
next section, we therefore extend the pattern-based approach presented in Section 3
with an algorithm that detects rigidity in prism structures.
43
Chapter 5
Prism rigidity detection
Due to the apparent lack of general rigidity detection theories that can be applied
to Lego models, we shall focus on improving the pattern-based, heuristic approach
that gave the triangle rigidity detection algorithms in Chapter 3.
I have chosen prism structures—defined in Section 4.2.2 and shown in Figures 4.5(a)–4.9(a)—as the focus of the heuristic approach. After triangles have
been treated, the prism structures seem to constitute the simplest kind of structure
in two dimensions for which the rigidity properties can be determined.
5.1
Rigidity rule
In order for us to be able to formulate a rule for the rigidity properties of prism
structures, we need to clarify under what circumstances we want to consider the
structures as rigid. If two rigid structures a and b both have connections to all rigid
structures in a set C of three or more rigid structures, then there are possibilities
for rigidity. Whether the whole structure is rigid or not depends on the relative
properties of the structures in C and how we choose to define rigidity.
We consider the prism structures 1–5 in Figures 4.5(a)–4.9(a). Prisms 1 and 2
are obviously nonrigid, since they can flex while keeping the three vertical bricks
parallel. That prism 5 is rigid is also obvious. As we discussed in Section 4.2.2,
the rigidity properties of prisms 3 and 4 are more problematic. However, following
the rules for the previously defined triangle rigidity, the top and bottom triangles
of prism 4 are also rigid, which makes that prism rigid as well.
The decision of whether prism 3 should be considered rigid or not is not simple
to make. In reality, the prism can make slight movements without flexing back.
However, we shall consider prism 3 rigid, following the previous decision to consider
prism 4 rigid. It is probable that these are the rigidity properties desired by Lego,
and this gives the following rule. Given two rigid structures that have connections
to at least three common rigid structures that are nonparallel or of nonequal length,
the whole structure is rigid.
Here, the terms “nonparallel” and “nonequal length” mean that at least one of
44
the rigid structures considered has a different direction or length from the others.
The direction of a rigid structure is defined as the vector between the two joints
that connect the rigid structure to the rest of the prism structure.
To simplify things, we consider only two-dimensional prisms, i.e. prisms where
all rotational axes are parallel. Also, no rotational axes can be coincident, because
this may complicate the case. We observe that if the rigidity detection were to be
extended to three dimensions, we would have to check that all rotational axes are
parallel and noncoincident.
5.2
Prerequisites
In order to create an algorithm for prism rigidity detection, we assume that some
functions are available to us.
• Each rigid structure must have a unique ID, and given a rigid structure, we
must be able to get its ID by calling the function GetID().
• Given a rigid structure, we must be able to get a list of the connections it has
to other rigid structures by calling GetConnections().
• Given a connection and a rigid structure on one of its sides, we must be
able to get the rigid structure on the other side of the connection by calling
GetRigidStructure().
• Given two connections, we must be able to create the Euclidean vector from
one connection to the other using the command Vector().
• Given a vector, we must be able to get its length by calling GetLength().
• Given two vectors, we must be able to determine whether they are parallel by
calling isParallel().
• Finally, given two rigid structures, we must be able to merge them by calling
Merge(). The connections of the rigid structures should be updated according
to the properties of the new rigid structure.
5.3
Algorithm
When we want to detect rigidity in prism structures, we consider a brick that has
just been added to the structure. We assume that we can take the largest rigid
structure achieved through triangle rigidity detection that our added brick is a part
of (from now on referred to as the added rigid structure) as parameter (line 01 in
our algorithm PrismRigidity in Figure 5.1). Thereby, we also have the connections
from that structure to other rigid structures (line 02).
45
01 Algorithm PrismRigidity(rs1)
02
conns1 = rs1.GetConnections()
03
If (conns1.GetSize() ≥ 3)
04
If (PrismRigiditySub(rs1))
05
Return (True)
06
If (conns1.GetSize() ≥ 2)
07
For Each conn1 In conns1
08
rs2 = conn1.GetRigidStructure(rs1)
09
conns2 = rs2.GetConnections()
10
If (conns2.GetSize() ≥ 3)
11
If (PrismRigiditySub(rs2))
12
Return (True)
13
Return (False)
Figure 5.1. Outer algorithm for detecting prism rigidity.
In order for this rigid structure to be part of a prism structure, two cases
are possible. The rigid structure is either (1) one of the two structures a and b
(lines 03–05)—or (2) one of the three (or more) structures in the set C (lines 06–12).
We first consider case 1. If the added rigid structure has three or more connections to other rigid structures, then there are possibilities for prism rigidity (line 03).
We therefore let our subroutine PrismRigidity check if the added structure has at
least three connections leading to rigid structures that connect to a common rigid
structure, and if these structures have the correct properties for rigidity (line 04).
If rigidity is detected, we exit our algorithm (line 05).
If the added rigid structure does not have three or more connections to other rigid
structures, or the rigidity requirements in case 1 are not fulfilled, then rigidity is still
possible through case 2. If the added rigid structure has two or more connections
to other rigid structures (line 06), we check if any of the rigid structures on the
other side of these connections fulfil the requirements for prism rigidity in case 1
(lines 07–12). If a rigid structure on the other side has three or more connections
to other rigid structures (lines 08–10), then we let our subroutine examine if this
structure is part of a rigid prism (line 11), and if rigidity is found, we exit our
algorithm (line 12).
If the added rigid structure is not part of a rigid prism structure either through
case 1 or case 2, then we exit our algorithm without any changes to the rigid structure model (line 13).
Now let us see how our subroutine takes on the rigid structure it receives as
parameter (the received rigid structure) (line 01 in our subroutine PrismRigidity2
in Figure 5.2). After initiating some variables (lines 02–04), we get the connections
of the received rigid structure (line 05) and examine each of these (lines 06–13).
For each of the connections of the received rigid structure (line 06), we get the
46
01 Subroutine PrismRigiditySub(rs1)
02
conns1 = rs1.GetConnections()
03
Reset counters[]
04
Reset connlists1[]
05
Reset connlists2[]
06
For Each conn1 In conns1
07
rs2 = conn1.GetRigidStructure(rs1)
08
conns2 = rs2.GetConnections()
09
For Each conn2 6= conn1 In conns2
10
id = conn2.GetRigidStructure(rs2).GetID()
11
counters[id] = counters[id] + 1
12
connlists1[id].Add(conn1)
13
connlists2[id].Add(conn2)
14
For id = 1 To counters.size()
15
If (counters[id] ≥ 3)
16
Reset vectors[]
17
For j = 1 To connlists1[id].GetSize()
18
vectors[j] =
Vector(connlists1[id].Get(j), connlists2[id].Get(j))
19
For j = 1 To vectors.GetSize() − 1
20
If (Not vectors[j].isParallel(vectors[j + 1])
Or vectors[j].GetLength() 6=
vectors[j + 1].GetLength())
21
For j = 1 To connlists1[id].GetSize()
22
rs1 = rs1.Merge(connlists1[id].
get(j).GetRigidStructure(rs1))
23
rs1 = rs1.Merge(connlists2[id].Get(1).
GetRigidStructure(rs1))
24
Return (True)
25
Return (False)
Figure 5.2. Inner algorithm for detecting prism rigidity.
47
rigid structure on the other side of the connection (line 07), get the connections of
this rigid structure (line 08), and go through each of these (lines 09–13).
For each unique rigid structure we reach through these connections (the reached
rigid structures) (line 09), we count the number of ways in which it can be reached
(lines 10–11) and record the connections through which it is reached (lines 12–13).
An intuitive way to think about this procedure is to look at the structure in
Figure 3.10; if we assume that we start out from the bottom brick (choosing the
top brick is equivalent), we list all potential top bricks and the different ways of
reaching them.
Now that we have recorded all rigid structures that can be reached from the
added rigid structure via another rigid structure, we examine which of these that
actually form a rigid prism together with the added structure (lines 14–24).
For each reached rigid structure (line 14), we check if it can be reached via at
least three other rigid structures (line 15). If so, we create a list of the Euclidean
vectors between the two joints in each joint pair leading to the current reached
rigid structure (lines 16–18). Then, we compare the vectors to see if at least one
is not parallel to or does not have the same length as the others (lines 19–20). (If
another definition of rigidity of prism structures is desired, this is the requirement
to change.) If one vector is nonparallel to the others, or differs in length, then we
merge all rigid structures connecting the received rigid structure and the reached
rigid structure with the received rigid structure (lines 21–22). Finally, we merge this
new structure with the reached rigid structure (line 23); the prism now constitutes
a single rigid structure, and we can exit our subroutine (line 24).
If no reached rigid structure is found to form a rigid prism together with the
received rigid structure, then we exit our subroutine with no changes made to the
rigid structure model (lines 25).
If no updates of the rigid structure model have been made after PrismRigidity
has been called, then the rigidity detection is finished. If, on the other hand, the rigid
structure has been updated, repeated rigidity detection should be performed. Both
the triangle and the prism rigidity detection procedures must be repeated, because
new structures of either form can possibly have been formed via the first prism
rigidity detection. This procedure is repeated until neither the triangle rigidity
detection nor the prism rigidity detection lead to any changes in the rigid structure
model.
5.3.1
Time complexity
In this calculation of the time complexity of our algorithm, we let r be the number
of rigid structures in the model before PrismRigidity is called.
We first look at PrismRigidity2. The time for getting a reference to the connections of the received rigid structure and initializing the variables is constant.
There are at the most r − 1 connections to other rigid structures, so lines 07–09
are repeated at the most r − 1 ∈ O(r) times. The time for getting references to
the next rigid structure and its connections is constant. There are at the most
48
r − 2 connections to new rigid structures, so lines 10–13 are repeated at the most
(r − 1)(r − 2) ∈ O(r2 ) times. Getting the ID of a rigid structure, increasing the
counter, and recording the connections take constant time, which conclusively lets
us run lines 02–13 in a time complexity of O(r2 ).
There are, accordingly, at the most r − 2 IDs to run through, so lines 15–17 are
repeated at the most r − 2 ∈ O(r) times. There are at the most r − 2 connection
pairs to calculate vectors for, and calculating a vector given two connections takes
constant time, so lines 15–18 run in (r − 2)2 ∈ O(r2 ) time. Then, there are at
the most r − 2 vectors to go through line 19, so line 20 is repeated at the most
(r − 2)2 ∈ O(r2 ) times.
When a prism structure fulfils the requirements for rigidity and the different
parts of the prism should be merged (lines 21–23), there are at the most r − 2
connections to go through, so line 22 is repeated at the most (r − 2) ∈ O(r) times.
The time for merging two rigid structures is assumed to be O(r), since there are
r − 1 possible connections to transfer, and thus the time for running lines 20–23
is O(r2 ). However, since the merging only takes place at the most once for each
call to PrismRigidity2, this conclusively makes the worst-case time complexity for
lines 14–24, and accordingly the whole PrismRigidity2 subroutine, O(r2 ).
In PrismRigidity, all function calls except the calls to PrismRigidity2 take
constant time. PrismRigidity2 can be called at the most r times, which gives a
total worst-case time complexity of O(r3 ) for our prism rigidity detection algorithm.
Although this time can grow large for large r, it should be pointed out that the
average time for performing the prism rigidity detection is most likely considerably
lower; when the number of rigid structures is large, it is unlikely that a single rigid
structure would be connected to a number of other rigid structures that is close to
r.
5.3.2
Implementation
No implementation of the prism rigidity detection algorithm in the Digital Designer
application has been performed. Accordingly, I have not tested the algorithm on
Lego models built in the application. The analysis of the relevance of this kind
of rigidity detection is therefore limited to a brief discussion, as seen in the next
section.
5.4
Relevance
A relevant question to ask is if the detection of rigid prisms actually improves the
existing rigidity detection in the Digital Designer application. If prism structures
were common in Lego models, this would certainly be the case; unfortunately, there
are not many indications of this.
I have not been able to perform tests of my own on the 15 models described
in Section 3.3.2. Since tests should preferably be performed on actual models built
by users (or by Lego), no tests on hypothetical models have been performed here.
49
Consequently, we can only draw conclusions regarding the relevance of our prism
rigidity detection algorithm on the grounds of the information found in [8].
Out of the 15 test models, the rigidity properties of 11 of them are completely
detected using double connection and triangle rigidity algorithms. Out of the 4
remaining models, the incomplete rigidity detection is due to physical rotational
limitations. Since this kind of rigidity is at this stage planned to be handled by the
physics engine, only 1 of the 15 test models (“Monkey”) leaves room for improvements in the rigidity detection.
It is unclear whether the rigidity detection in “Monkey” would be improved by
our prism rigidity detection algorithm. The information given in [8] rather implies
the opposite, since the problematic structures mentioned (shown in Figure 3.9 a)
and b)) are not prism structures. However, no certain conclusions can be drawn regarding the relevance of our prism rigidity detection algorithms until proper research
has been carried out. This research would preferably analyse a larger selection of
user-built models.
Still, one observation can be made; it is possible that prism structures would
be more common in structures built with Technics bricks. These bricks are more
aimed towards flexible joint connections, and as a consequence more structures that
are rigid on other grounds than triangle shapes could occur. Once again, however,
these possibilities are purely speculative until further research in the matter has
been performed.
50
Chapter 6
Conclusion
We have investigated the possibilities of improvements in the area of rigidity detection in virtual Lego models in the Digital Designer application.
First, we described the results previously achieved in the context of rigidity
detection in virtual Lego models; this mainly regarded two algorithms for triangle
rigidity detection presented in a Bachelor’s thesis.
Then, we investigated the potential of two fields of theory for the rigidity detection, namely framework rigidity and generic rigidity. The most serious shortcomings of framework rigidity were its lack of methods for detecting rigid structures, the potentially very large rigidity matrix size—and thereby cumbersome rank
calculations—and its compliance with infinitesimal rigidity instead of the regular
rigidity desired in the Digital Designer application. Generic rigidity most importantly suffered from the loss of geometric information—which lead to incorrect
calculations of rigidity properties—and the fact that Laman’s theorem does not
generalize to three dimensions for general graphs.
Therefore, we finally focused on a heuristic, pattern-based approach. We presented an algorithm in pseudo code running in O(r3 ), where r is the number of
rigid structures in the model, that detects prism structures and examines them for
rigidity. The algorithm was not implemented.
Since both framework rigidity and generic rigidity have serious shortcomings
when it comes to rigidity detection in virtual Lego models, it would be interesting
to find theories that cover the gap between the two investigated theoretical fields.
In [6] and [7], an approach with the aim of accomplishing this is presented. A new
kind of characterization of rigidity, the extended structural rigidity, is described. It
is based on a new geometric concept, the degree of rigidity, which is related to the
concept of degree of freedom. It has not been within the scope of this thesis to
cover this area of theory; however, it should indeed be investigated, as the approach
seems promising and could appear fruitful.
Conclusively, we must however emphasize the need for further investigations of
heuristic approaches. This is where we managed to make improvements, but there
are probably many areas left to cover.
51
One such potential area of research is structures containing joints with nonparallel rotational axes. Since we have focused on two dimensions, the prism structure
containing two rigid structures connected by three other rigid structures is the
simplest we have found. However, if three dimensions are considered, further investigations could be made regarding structures containing four (or more) joints with
nonparallel rotational axes.
Also, this thesis, as well as [8], focuses on the scenario of a brick being added
to a model. When bricks are removed, the rigidity properties of a structure can
change considerably, and therefore the removal of bricks is also an important area
of research.
Finally, most of the research done so far seems to be treating the traditional Lego
System bricks. Adding the domain of Technics bricks to the Digital Designer application complicates the rigidity detection considerably, since there are more complex
Technics bricks than the joint bricks mentioned here. There seems to be plenty
of work to be done before sufficiently general and efficient motion computations in
Digital Designer are a reality.
52
Bibliography
[1] D. S. Franzblau, Combinatorial algorithm for a lower bound on frame rigidity, SIAM Journal on Discrete Mathematics 8 (1995), 388–400.
[2] D. S. Franzblau, Generic rigidity of molecular graphs via ear decomposition,
Discrete Applied Mathematics 101 (2000), 131–155.
[3] D. J. Jacobs, Generic rigidity in three-dimensional bond-bending networks,
Journal of Physics A: Mathematical and General 31 (1998), 6653–6668.
[4] D. J. Jacobs, 2D Pebble game, Java applet, available 9/3/2006 at
http://flexweb.asu.edu/software/pebble_game/.
[5] D. J. Jacobs & B. Hendrickson, An algorithm for two-dimensional rigidity
percolation: The pebble game, Journal of Computational Physics 137 (1997),
346–365.
[6] C. Jermann, B. Neveu & G. Trombettoni, Algorithms for identifying rigid
subsystems in geometric constraint systems, 18th International Joint Conference in Artificial Intelligence, IJCAI-03 (2003), 233–238.
[7] C. Jermann, B. Neveu & G. Trombettoni, A new structural rigidity
for geometric constraint systems, Automated Deduction in Geometry: Lecture
Notes in Artificial Intelligence 2930 (2004), 87–106.
[8] N. Kjeldsen, Detektion af rigide strukturer i virtuelle Lego-modeller (“Detection of rigid structures in virtual Lego models”), Bachelor’s thesis (2005).
[9] G. Laman, On graphs and rigidity of plane skeletal structures, Journal of
Engineering Mathematics 4 (1970), 331–340.
[10] The Lego® Group, Lego Digital Designer, application, available 9/3/2006
for free download at http://www.lego.com/eng/factory/design/ldd.asp.
[11] The Lego® Group, Lego.com, web site, available 9/3/2006 at
http://www.lego.com/.
[12] The Mathworks, Inc., rank (MATLAB Functions), web site, available
18/5/2006 at
http://www.mathworks.com.au/access/helpdesk/help/techdoc/ref/rank.html.
53
[13] C. Moukarzel, An efficient algorithm for testing the generic rigidity of graphs
in the plane, Journal of Physics A: Mathematical and General 29 (1996), 8079–
8098.
[14] A. Recski, Matroid Theory and Its Applications in Electric Network Theory
and in Statics, ISBN 3-540-15285-7, Springer (1989).
[15] B. Servatius & H. Servatius, Generic and abstract rigidity, in Rigidity Theory and Applications, M. F. Thorpe & P. M. Duxbury, eds., Springer (1999),
1–22.
[16] Various authors, 3D building application for children, 51st European Study
Group with Industry (2004), 59–99, available 9/3/2006 at
http://www.mat.dtu.dk/ESGI/51/Report/esgi51.pdf.
54
Appendix A
Triangle rigidity test model data
Table A.1. Average runtime in µs for five runs of rigidity detection of the whole
models using the three different algorithms.
Baseball
Chopper
Crab
Fighter
Fighter 2
House
Kangaroo
Monkey
Nitendo DS
Plane
Red Widow
Robot
Stage
Tie Fighter
VAB
Without triangle
rigidity detection
649.4
101.8
394.2
94.8
231.0
1246.6
369.2
793.8
640.8
148.2
1474.8
162.6
582.7
108.4
2611.2
Using
CheckForTriangles
971.6
126.8
475.2
153.4
357.4
1774.4
668.4
4674.8
780.8
178.4
2463.2
199.6
590.6
132.2
3668.8
55
Using
CheckForTrianglesMapImplementation
1042.6
157.8
991.8
260.8
452.6
1961.4
793.2
8304.4
781.8
241.4
3260.2
249.4
585.6
142.6
4201.8
Table A.2. Correctness and completeness of the triangle rigidity detection algorithms. C - Assumed correct detection; the models were not built in reality, so it
was not possible to make a precise estimation of the correctness of the detection. P
- Physical rotational problems; an implementation of physical rotational limitations
could detect further rigidity. I - Incomplete detection; recognition of one or more
rules is missing, and the addition of recognition of these rules would improve the
rigidity detection.
Baseball
Chopper
Crab
Fighter
Fighter 2
House
Kangaroo
Monkey
Nitendo DS
Plane
Red Widow
Robot
Stage
Tie Fighter
VAB
Rigid
structures
without
triangle
rigidity
detection
2
3
43
11
6
14
15
97
3
1
83
16
13
9
26
Rigid
structures
with
triangle
rigidity
detection
2
3
43
11
6
14
10
43
3
1
83
16
13
9
24
56
Triangles
1
0
0
1
0
1
1
15
0
0
4
0
0
0
10
Bricks
238
46
187
44
104
542
155
247
314
71
377
73
269
48
1092
Evaluation
C
C
C
P
P
P
C
I+P
C
C
C
C
C
C
C
Appendix B
Matlab program
for rigidity matrix rank computation
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
d = 2;
JOINTS = load(’joint_data_graph_1.txt’);
BARS = load(’bar_data.txt’);
JOINTS_SIZE = size(JOINTS);
v = JOINTS_SIZE(1, 1)
BARS_SIZE = size(BARS);
e = BARS_SIZE(1, 1)
ADJ = zeros(v, v);
A = zeros(e, d*v);
for i = 1:e
ADJ(BARS(i,1), BARS(i, 2)) = 1;
ADJ(BARS(i,2), BARS(i, 1)) = 1;
for j = 1:d
A(i, BARS(i, 1) + (j - 1)*v) =
JOINTS(BARS(i, 1), j) - JOINTS(BARS(i, 2), j);
A(i, BARS(i, 2) + (j - 1)*v)
JOINTS(BARS(i, 2), j) - JOINTS(BARS(i, 1), j);
end
end
rank(A)
gplot(ADJ, JOINTS, ’-ok’)
axis square
axis off
57
TRITA-CSC-E 2006: 109
ISRN-KTH/CSC/E--06/109--SE
ISSN-1653-5715
www.kth.se