Skip to main content

Computing Storyline Visualizations with Few Block Crossings

Part of the Lecture Notes in Computer Science book series (LNTCS,volume 10692)

Abstract

Storyline visualizations show the structure of a story, by depicting the interactions of the characters over time. Each character is represented by an x-monotone curve from left to right, and a meeting is represented by having the curves of the participating characters run close together for some time. There have been various approaches to drawing storyline visualizations in an automated way. In order to keep the visual complexity low, rather than minimizing pairwise crossings of curves, we count block crossings, that is, pairs of intersecting bundles of lines.

Partly inspired by the ILP-based approach of Gronemann et al. [GD 2016] for minimizing the number of pairwise crossings, we model the problem as a satisfiability problem (since the straightforward ILP formulation becomes more complicated and harder to solve). Having restricted ourselves to a decision problem, we can apply powerful SAT solvers to find optimal drawings in reasonable time. We compare this SAT-based approach with two exact algorithms for block crossing minimization, using both the benchmark instances of Gronemann et al. and random instances. We show that the SAT approach is suitable for real-world instances and identify cases where the other algorithms are preferable.

The full version of this paper is available on arXiv [4].

F. Lipp was supported by Cusanuswerk.

1 Introduction

A storyline visualization is a particular abstraction of the structure of a narrative. A good visualization reveals the underlying structure by removing the details of how the story is presented and, instead, focusing on which entities interact as time passes within the narrative. This type of diagram was originally conceived to visualize meetings between characters in movies and, though it has since been interpreted more generally as an elegant way to visualize a sequence of interconnected interactions over time, the term storyline visualization remains.

In a storyline visualization, each character is represented by an x-monotone curve in the plane; we will refer to curves and characters interchangeably. Time goes from left to right, and a meeting between a set of characters (occurring for the duration of a given time interval) is represented by a corresponding region in the plane where those curves come closely together. This drawing style is commonly attributed to Munroe [12], who represented several popular movies in this fashion. See Fig. 1 for an example drawn using our system.

Block Crossings in Storyline Visualization. When formalizing the drawing of storyline visualizations as an optimization problem, it is natural to minimize the number of crossings among the characters. As with graph drawing in general, this is not the be-all-end-all objective. For example, two groups of curves crossing each other in a grid structure are easier to understand visually than the same number of crossings scattered wildly throughout the drawing. In this paper we continue the study of such block crossings in storyline visualization.

Intuitively, a block crossing consists of two sets of locally parallel curves intersecting each other without any further curves in the crossing area [3]. (A formal definition is given below.) In the design of his movie narrative charts, Munroe seems aware (at least implicitly) of the concept of block crossings. Indeed, the Gestalt principle of “continuity” or “good continuation” [14] suggests that block crossings are easier to read, but what exactly makes the most readable drawing should be analyzed in proper user studies. Here we focus on practical computational aspects, having decided to minimize block crossings.

Concurrent Meetings. An important modeling decision that the literature has handled variously is whether it is possible for multiple meetings to occur at overlapping time intervals. Some papers define the input to the storyline visualization problem such that these concurrent meetings are impossible, for example by representing the meetings as a totally ordered set. Whether or not it is important to support concurrent meetings is open for discussion. One could, for example, represent each scene of a movie as a separate meeting that includes precisely the characters that participate: then meetings do not overlap. However, this is a rather mechanical interpretation of what storyline visualizations are for. Indeed, rather than strictly following the order of appearance in the movies, Munroe’s “movie narrative charts” [12] visualize the spatio-temporal structure underlying the story, rather than the presentation of the story: the x-axis in his charts represents time within the story, not time in the movie.Footnote 1 This paper supports concurrent meetings.

Previous Work. Tanahashi and Ma [13] computed storyline visualizations automatically and discuss various aesthetic criteria to be optimized. Kim et al. [9] used storylines to visualize genealogical data: meetings correspond to marriages and special techniques are used to indicate child–parent relationships.

Kostitsyna et al. [11] formalized the problem of crossing minimization for storylines. Their aim was to minimize the number of pairwise crossings (that is, not block crossings) in storylines. They proved the problem NP-hard, presented an FPT algorithm, and gave an upper bound on the number of crossings in a restricted setting. Gronemann et al. [8] designed an integer linear program (ILP) to minimize the number of pairwise crossings and evaluated it experimentally. Their approach is able to solve instances with 10–20 characters and up to about 50 meetings from real-world movies (and to a lesser degree, books) to optimality in a few seconds.

In an earlier paper [3], we introduced the concept of minimizing block crossings for drawing storylines. We showed that block crossing minimization in storylines is NP-hard. For special cases, we provided an approximation algorithm. Of particular relevance to the current paper are two exact algorithms, one of which is fixed-parameter tractable (FPT) in the number of characters.

The current paper improves on the above in two ways. Firstly, we have developed a new SAT-based algorithm for computing optimal storyline visualizations. We note that SAT formulations have been used before in graph drawing, for example by Bekos et al. [2]. Whereas we previously restricted ourselves to meetings that are points in time, we now handle concurrent meetings. (This more general problem is clearly NP-hard as well.) Secondly, we have now implemented the exact algorithms of our earlier paper [3], which enables an experimental evaluation and comparison. We see that the new algorithm is able to handle larger realistic instances than our previous algorithms, but that the FPT algorithm also has practical relevance.

Problem Definition. We generalize the problem statement compared to our previous paper [3] in order to handle the instances used by Gronemann et al. [8]. In this more general statement, we support meetings that span a certain amount of time (instead of allowing only instantaneous meetings); thus, meetings can overlap with other meetings. Additionally, we allow for birth and death of characters, that is, each character is only drawn in the storyline during its lifespans (being a set of time intervals).

A storyline \(\mathcal {S} \) is a triple (CME) where \(C = \{1, \dots , \kappa \}\) is a set of characters, \(M = \{m_1, m_2, \dots , m_n\}\) is a set of meetings, and \(E :C \rightarrow \mathcal {P}(\mathbb {I}\mathbb {R})\) describes the lifespans of a character with \(\mathbb {I}\mathbb {R} \) being the set of intervals of real numbers. A meeting \(m_j\) is a triple \((s_j, e_j, C_j)\) where \(s_j \in \mathbb {R} \) is the start time of the meeting, \(e_j \in \mathbb {R} \) is the end time of the meeting, \(s_j < e_j\), and \(C_j \subseteq C\) contains the involved characters. A meeting \(m_j\) is said to be active at time \(t \in \mathbb {R} \) if \(t \in [s_j, e_j)\). The set \(E(i) = \{[b_i^1, d_i^1), \dots , [b_i^{\eta _i}, d_i^{\eta _i})\}\) contains the lifespans of character i, that is, \(\eta _i\) disjoint time intervals, in which the character is alive. For each of these time intervals (\(1 \le \iota \le \eta _i\)), \(b_i^\iota \) describes the “birth” while \(d_i^\iota \) describes the “death” of the character. Character i is said to be alive at time \(t \in \mathbb {R} \) if \(t \in I\) for some \(I \in E(i)\).

We forbid that a character participates in two meetings at the same time: in our drawing style, it wouldn’t be possible to distinguish the two groups. More formally, for any two meetings \(m_j, m_\ell \) with \(s_j< s_\ell < e_j\), we require that \(C_j \cap C_\ell = \emptyset \). Obviously, character i can only be part of a meeting \(m_j\) if i is alive during the time span of the meeting, that is, if \([s_j,e_j)\subseteq I\) for some \(I \in E(i)\). In particular, a character cannot be born or die during a meeting.

A solution for a storyline instance \(\mathcal {S} = (C, M, E)\) consists of a sequence \(\varPi = [\pi _1, \dots , \pi _\lambda ]\) of permutations of subsets of C and a nondecreasing function \(A :\mathbb {R} \rightarrow \{1, \dots , \lambda \}\) describing the connection between points in time and the permutations in the solution. A solution is admissible if it fulfills the following conditions.

  1. (a)

    For any point in time \(t \in \mathbb {R} \),

    1. (i)

      \(\pi _{A(t)}\) contains exactly the characters that are alive at time t, and

    2. (ii)

      for any meeting that is active at time t, its set of characters must be a contiguous block in \(\pi _{A(t)}\).

  2. (b)

    For \(p \in \{2,\dots ,\lambda \}\):

    1. (i)

      If the character sets of \(\pi _{p-1}\) and \(\pi _p\) are identical, then either \(\pi _{p-1}\) and \(\pi _p\) are identical or they differ in a block crossing, that is, two adjacent blocks of characters switch their order. Suppose that, after renumbering, \(\pi _{p-1} = \langle 1, \dots , a, \dots , b, \dots , c, \dots , \kappa \rangle \). Then exchanging the two adjacent blocks \(\langle a,\dots ,b \rangle \) and \(\langle b+1,\dots ,c \rangle \) yields the permutation \(\pi _p = \langle 1, \dots , a-1, b+1, \dots , c, a, \dots , b, c+1, \dots , \kappa \rangle \).

    2. (ii)

      If the character sets of \(\pi _{p-1}\) and \(\pi _p\) are not identical, then their intersection must be in the same order in \(\pi _{p-1}\) and in \(\pi _p\). They need not remain contiguous.

Now we can formally state the problem that we consider in this paper, General Storyline Block Crossing Minimization: Given a storyline instance (CME), find an admissible solution \((\varPi , A)\) that minimizes the number of block crossings.

We define \(\mathcal {E} \) to be the finite set of events, that is, points in time, at which a meeting starts or ends or a character is born or dies. Our aim is to find the smallest number \(\lambda _\mathrm {OPT}\) of permutations that accommodates all events subject to the constraints above. This also minimizes the number of block crossings \(\mathrm {bc}_\mathrm {OPT}\) since \(\mathrm {bc}_\mathrm {OPT} = \lambda _\mathrm {OPT} - |\mathcal {E} '| + 1\), where \(\mathcal {E} '\) denotes the points in time at which at least one character is born or dies (including the birth of the first character and death of the last character in the storyline).

Our Results. Partly inspired by the ILP from Gronemann et al. [8], we developed a SAT formulation of the problem that can be used to decide whether there is a solution using a fixed number of permutations (and, hence, block crossings); see Sect. 2. Initial experiments with a similar ILP model performed poorly and led us to explore SAT solvers. We experimentally compare our new SAT approach to the two exact algorithms from our previous paper [3]; see Sect. 3. The source code of all three implementations is available onlineFootnote 2.

2 SAT Formulation for the Decision Problem

We present a SAT formulation that encodes, for a given storyline \(\mathcal {S} \) and an integer \(\lambda \), whether there is a solution whose sequence of permutations consists of exactly \(\lambda \) elements. From a satisfying truth assignment we can derive the solution for \(\mathcal {S} \). The optimal number of block crossings can then be found using this decision problem by searching for the minimum satisfiable \(\lambda \), for example using linear or exponential search. Our formulation is inspired by the ILP of Gronemann et al. [8], which minimizes the number of pairwise crossings in a storyline visualization.

In the following, we do not always describe the clauses in conjunctive normal form, using other operators where this improves readability. The transformation into conjunctive normal form is straightforward. For the sake of completeness, the result of this transformation is shown in the full version [4, Appendix A]. In the following, unless specified or bound otherwise, the variables and clauses are quantified over all \(i,j,k \in C\) with \(i \ne j\), \(i \ne k\), \(j \ne k\) and all \(r,p \in \{1, \dots , \lambda \}\), \(r \ne p\), and \(\ell \in \{1, \dots , \mu \}\), where \(\mu \) is the number of meeting groups, a concept we introduce later on.

Describing the Permutations. To describe a solution, we start with the sequence of permutations \(\varPi = [\pi _1, \dots , \pi _\lambda ]\). Each permutation \(\pi _r\) is represented by Boolean variables of type \(x_{ij}^r\). These variables describe the relative order of the characters in the permutation. The truth assignment of variable \(x_{ij}^r\) indicates whether character i is above character j in permutation \(\pi _r\). To handle “dead” characters, we introduce another set of variables \(o_i^r\). Character i is omitted in permutation \(\pi _r\) if and only if \(o_i^r\) is true. The clauses described here and under the following two headers (constraints for permutations, crossings between characters, and block crossings) are only active if all involved characters are available (that is, \(\lnot o_i^r\)) in the permutation considered. We model this by adding \(o_i^r\) as a positive literal to each clause for each affected character i.

To ensure that the variables describe a permutation, we add the following clauses. We guarantee antisymmetry by \(x_{ij}^r \Leftrightarrow \lnot x_{ji}^r\). We ensure transitivity by \(x_{ij}^r \vee x_{jk}^r \vee x_{ki}^r\) and \(\lnot x_{ij}^r \vee \lnot x_{jk}^r \vee \lnot x_{ki}^r\); this forces one of the three variables to have a different value than the others.

Crossings Between Characters. To simplify the treatment of crossings, we introduce variables that indicate when they occur. For \(r \in \{1, \dots , \lambda - 1\}\), variable \(\chi _{ij}^r\) encodes whether characters i and j have a crossing between permutations r and \(r+1\). This is the case precisely if they change their relative order between the two permutations, that is: \(\chi _{ij}^r \Leftrightarrow (x_{ij}^r \ne x_{ij}^{r+1})\) for all \(r \in \{1, \dots , \lambda - 1\}\). Note that this – together with the previously described clauses – implies \(\chi _{ij}^r \Leftrightarrow \chi _{ji}^r\). (Recall that constraints involving omitted characters are “switched off” using the variables of type \(o_i^r\)).

According to our problem definition we have to ensure that if there is an addition or removal of characters between successive permutations, then there can be no block crossing. So we forbid crossings for all pairs of characters between permutation \(\pi _r\) and \(\pi _{r+1}\) if a character i is added or removed between these permutations: \((o_i^r \ne o_i^{r+1}) \Rightarrow \lnot \chi _{jk}^r\) for all \(r \in \{1, \dots , \lambda -1\}\).

Block Crossings. By the problem definition, there is at most one block crossing between any two successive permutations \(\pi _r\) and \(\pi _{r+1}\). We describe this block crossing by partitioning the character set of permutation \(\pi _r\) into three sets \(F_r\), \(G_r\), and \(H_r\). For simplicity, we drop the subscript r in the following. We express the membership of a character i in any of these sets using variables \(f_i^r\), \(g_i^r\) and \(h_i^r\), respectively. Let G and H be the two sets of characters that are involved in the potential block crossing between \(\pi _r\) and \(\pi _{r+1}\), and let F be the set of characters that are not affected by the crossing. If there is no block crossing between the two permutations, at least one of the two sets G and H is empty.

First we add clauses that ensure that every character is in one of the three sets, that is, exactly one of the variables \(f_i^r\), \(g_i^r\), and \(h_i^r\) is true. Next, the characters of G and the characters of H must each form a contiguous block. We enforce this by requiring that a character j is in G if j lies between two characters i and k in G: \(x_{ij}^r \wedge x_{jk}^r \wedge g_i^r \wedge g_k^r \Rightarrow g_j^r\). Similarly, for H we require \(x_{ij}^r \wedge x_{jk}^r \wedge h_i^r \wedge h_k^r \Rightarrow h_j^r\).

We ensure that the blocks G and H are adjacent, by requiring that no character in F lies between characters in G and in H: \(x_{ij}^r \wedge x_{jk}^r \wedge g_i^r \wedge h_k^r \Rightarrow \lnot f_j^r\). Additionally, we prescribe the order of the blocks G and H in the permutation by restricting the characters in G to be above the characters of H: \(g_i^r \wedge h_j^r \Rightarrow x_{ij}^r\).

Finally, we ensure that two characters cross each other if and only if they participate in the block crossings, that is, if one of the characters is in G and the other is in H: \(g_i^r \wedge h_j^r \Leftrightarrow \chi _{ij}^r\) for all \(r \in \{1, \dots , \lambda - 1\}\).

Meeting Groups. So far we have introduced various structural constraints to our variables, but we haven’t yet established the connection to our input storyline \(\mathcal {S} \). We implement this connection now through the concept of meeting groups. A meeting group is a set of meetings that contain a common point in time. Instead of the meeting triples (that is, a set of characters, start time, and end time), we only consider the character sets for the meeting group. Characters who are alive at that time, but are not part of any meeting, are added to the meeting group as a singleton meeting.Footnote 3 We transform the storyline \(\mathcal {S} \) to a sequence of meeting groups \(\mathcal {M} = [\mathcal {M} _1, \dots , \mathcal {M} _\mu ]\) by sorting the events in \(\mathcal {E} \) and putting together the meetings and live characters for each event in the correct order. We use \(\mathcal {M} \) only to construct our SAT instance; afterward we transform the satisfying assignment back into a solution for \(\mathcal {S} \).

We add variables that connect these meeting groups to the permutations of the solution. The variable \(q_\ell ^r\) indicates whether the meeting group \(\mathcal {M} _\ell \) is assigned to permutation \(\pi _r\). We require that every meeting group is assigned to exactly one permutation, that is, every group is assigned somewhere \((\bigvee _{r=1}^\lambda q_\ell ^r)\) and no group is assigned twice \((\lnot (q_\ell ^r \wedge q_\ell ^p))\).

The meeting groups must be assigned to permutations in the correct order. If we map \(\mathcal {M} _\ell \) to \(\pi _r\), \(\mathcal {M} _{\ell -1}\) has to be assigned to the same permutation or an earlier one: \(q_\ell ^r \Rightarrow \bigvee _{j=1}^r q_{\ell -1}^j\) for \(\ell \in \{2, \dots , \mu \}\). We can assume that the first meeting group is assigned to the first permutation, as it is not optimal to use block crossings before the first meetings. Therefore, we set \(q_1^1\) to true.

Next, we handle the birth and death of characters. Let \(\mathcal {L} _i\) be the meeting groups that contain character i. A permutation \(\pi _r\) should contain exactly the characters that are contained in the assigned meeting groups: those are precisely the alive characters. We add the clause \(q_\ell ^r \Rightarrow \lnot o_i^r\) if \(\mathcal {M} _\ell \in \mathcal {L} _i\) and the clause \(q_\ell ^r \Rightarrow o_i^r\) if \(\mathcal {M} _\ell \notin \mathcal {L} _i\). This makes sure that characters involved in meetings must be present and dead characters are omitted.

Note that we allow permutations to not have any meeting groups assigned to them. This is necessary, for example to allow multiple block crossings between successive meetings (which may be necessary in an optimal drawing [3]). However, such “loose” permutations can be exploited to avoid block crossings by omitting all characters for one permutation and reintroducing them afterward in an arbitrary order. To forbid this, for \(r = 2, \dots , \lambda \), if no meeting group is assigned to permutation \(\pi _r\), we do not allow characters to be removed or added in \(\pi _r\): \(\bigwedge _{\ell = 1}^\mu \lnot q_\ell ^r \Rightarrow (o_i^{r} = o_i^{r-1})\).

Finally, we come to the actual storyline visualization constraint: characters in a meeting must form a contiguous group in the corresponding permutation. We add clauses that prohibit characters that are not part of a meeting from being between characters in the meeting. That is, if characters i and k are part of a certain meeting in \(\mathcal {M} _\ell \) and j is not, we have \(q_\ell ^r \Rightarrow (x_{ij}^r = x_{kj}^r)\).

This concludes our SAT formulation. If the resulting formula has a satisfying assignment, a solution to our storyline block crossing minimization problem exists, and it is easy to extract the permutations. To get the function A that maps the time to the permutations, we have to remember which meeting group corresponds to which point in time.

Counting the quantifiers in the above construction shows that there are \(O(\lambda (\kappa ^2 + \mu ))\) variables and \(O(\lambda \mu (\lambda +\kappa ^3))\) clauses. The conjunctive normal form of this SAT formula can clearly be constructed from the storyline in polynomial time.

3 Experimental Evaluation

We refer to the approach from Sect. 2 as Sat. Additionally, we have implemented two exponential-time exact algorithms that minimize block crossings [3]. The first is a branching algorithm that searches for the shortest sequence of block crossings using iterative deepening depth-first search (ItD). This search strategy ensures low memory usage. The second algorithm is fixed-parameter tractable in the number of characters and works by performing a breadth-first search in an exponentially-large state graph. Note that these two algorithms do not support concurrent meetings, whereas Sat does. We also consider an algorithm by Gronemann et al. [8] that optimizes pairwise crossings.

Implementation Details. All implementations are written in , with the exception of some “driver” code in Python for Sat. Comparable effort has been put into optimizing each program. Memory usage was not optimized, but there are no flagrant memory inefficiencies.

Sat uses the SAT formulation from Sect. 2 and performs exponential search on \(\lambda \). We use Python to write CNF SAT instances in DIMACS format, to run minisat [5, 6] on these instances, and to perform the search; the exponential search uses factor 2. We have used version 2.2.0 of minisat.Footnote 4. As runtime of Sat, we report the total time spent by minisat. This includes all “real” work, as well as launching minisat for each formula and the time it spends reading the DIMACS files; it does not include the runtime of our Python code, which has unnecessarily-poor performance and would be unfair in comparison to the other algorithms.

ItD and Fpt are implemented in following the description in [3], including the data structure for block crossings and checking meetings. For ItD, we branch and “unbranch” on a single data structure rather than making copies. Fpt performs a breadth-first search in a large graph. We store the nodes explicitly in a flat array addressed by Lehmer codes [10]: this requires \(\Theta (\kappa !n)\) space, but enables efficient lookup. The edges of the graph are enumerated lazily using the “forward pointers” from the original paper.

Fig. 1.
figure 1

A snippet of a block-crossing optimal drawing of The Matrix based on the sequence of permutations found by Sat, and the start and end times of the meetings (visualized by the gray blocks). The drawing reflects the linear order of the events but not their absolute points in time.

All runtime experiments have been performed on an Intel® Core™ i5-2400 CPU at 3.10 GHz with 8 GB of RAM and running Windows 7. This configuration is in some contrast to the experimental setup of Gronemann et al.: a \(2 \times 10\)-core machine with 128 GB of RAM. Our implementations are single-threaded; their implementation, being based on CPLEX, presumably makes use of the available cores, but this is not reported explicitly.

Real-World Instances. We use the same real-world instances as Gronemann et al. [8]. These include three movies and chapters from several books. See Fig. 1 for a block-crossing optimal drawing of The Matrix computed using Sat. More drawings computed using Sat are found in the full version [4, Appendix B].

Table 1 compares our block crossing optimization to solutions optimized for pairwise crossings. It shows that the optimal number of block crossings is much lower than the optimal number of pairwise crossings. This decrease is not just counting things differently: Gronemann et al.’s drawing of The Matrix, for example, has the optimal number of 12 crossings and happens to have 8 block crossings, whereas we give an optimal drawing with 4 block crossings. Our drawing happens to have 33 pairwise crossings: this presents an interesting trade-off.

Table 1. Comparison of pairwise crossings (cr) and block crossings (bc) on movie instances; subscript OPT indicates the value that the algorithm optimized. The runtime of both approaches is similar, even on rather different machines (see Sect. 3 – “Implementation Details”.).

The book instances unfortunately present a strong challenge for our algorithms. Even though there are no concurrent meetings, the number of characters immediately disqualifies Fpt and the optimum is too large for ItD. This leaves Sat, but these instances (as modeled in Gronemann et al.) contain an extreme number of ‘births’ and ‘deaths.’ While this is convenient for their algorithm (or at least: not detrimental), our SAT formulation requires a large number of permutations to handle this. One might hope that – even though large – these formulas are still relatively easy for minisat: alas, they are not.

Finally, we look at the exponential search that Sat uses to find the optimal number of permutations. If testing a number of permutations takes exponential time (we are solving a SAT instance, after all), a single overestimate would be disastrous. However, on the real-world instances we observe fairly modest time for overestimated \(\lambda \) (see Fig. 2). This means exponential search can have a significant advantage over linear search. On the movie instances, using exponential search is indeed faster than linear search, but just by about a third.

Fig. 2.
figure 2

Runtime of minisat for different numbers of permutations on the movie instances. Recall that the number of permutations does not equal the number of block crossings.

Fig. 3.
figure 3

Total runtime of Fpt on 100 random instances from the uniform model with \(p=0.5\), increasing number of meetings, and \(\kappa \in \{3,4,5,6,7\}\).

Fig. 4.
figure 4

Circular marks: runtime of Sat on instances from the uniform model with \(p=0.5\), and \(\kappa =5\) (left) and \(\kappa =9\) (right). Crosses, left plot: runtime of ItD. It is highly variable and practically dominated by Sat.

Random Instances. We test using random instances of two kinds. The first are uniform instances and these are the same as in previous work [3]. First, pick \(\kappa \), n, and a probability p. (We report here on \(p=0.5\).) Then generate a meeting by picking, independently at random with probability p, whether each character is in the meeting. Reject meetings with fewer than two characters, and repeat until there are n meetings. We let all characters be alive at all times, so we can run all three algorithms.

Figure 3 shows the runtime of Fpt on these instances as a function of n, for various numbers of characters. It confirms the fixed-parameter tractable runtime in practice. Note that the plot reports the runtime for solving 100 instances. The other algorithms have trouble handling 1000 meetings in any reasonable setting; with \(\kappa =5\), Fpt solves 100 such instances in little more than a second. However, the explosive dependence on \(\kappa \) is also clear.

Figure 4 similarly shows the runtime of Sat. Since there is more variance, we show 10 data points for every number of meetings, rather than the sum. For \(\kappa =5\), Sat can easily handle 100 meetings: except for an outlier, we are not yet hit by a runtime explosion. Note, however, that it is significantly slower than Fpt: approximately three orders of magnitude at \(n=100\). As for ItD: it is so slow on these instances that its runtime escapes the plot almost immediately.

For \(\kappa =9\), a different picture develops. Firstly, Sat experiences difficulty as the number of meetings increases. With instances approaching 50 meetings, the runtime starts to explode. For these instances, the runtime of Fpt is similar since it too has become slow at \(\kappa =9\). The difference is that, if we are willing to wait longer, Sat can be run on instances with more than 9 characters, whereas Fpt is quite fundamentally limited by its memory usage (see “Memory Usage”).

Yet another picture emerges when we look at instances that have a solution with few block crossings. To consider such instances is fair since in practice we are particularly interested in instances that can be realized with few block crossings. First, pick \(\kappa \), n, a probability p, and a number \(\beta \): we generate random instances that have optimum at most \(\beta \) as follows. Start from the identity permutation and sample \(\beta \) uniformly-random block crossings: this results in a sequence of \(\beta +1\) permutations. Now generate n meetings: pick, for each one independently, one of the permutations at random and then c adjacent characters from this permutation at random, where c is binomially distributed with success probability p so as to match the uniform model; put these meetings in the order of the permutations they come from. By construction, these instances have a solution with (at most) \(\beta \) block crossings.

Figure 5 shows that Sat and ItD can solve much larger instances of this kind. This is as expected, since \(\beta \) directly bounds the branching depth of ItD and the number of permutations required by Sat. We see that Sat practically dominates ItD; the only reason to use ItD is if no high-quality SAT solver is available, or if memory usage is important (the redeeming quality of ItD).

Fig. 5.
figure 5

Circular marks: runtime of Sat on random instances from the small-opt model with \(p=0.5\), and \(\kappa =5\) (left) and \(\kappa =10\) (right). Crosses, left plot: runtime of ItD. It is highly variable and practically dominated by Sat.

Memory Usage. Table 2 shows that the (peak) memory usage of the algorithms is quite different. ItD is implemented to branch with a single data structure. This is good for runtime (no copying), and has the additional benefit that memory usage is very low. In fact, it is hardly impacted by recursion depth since we use iterative deepening depth-first search and, rather than having the entire data structure at each level of the recursion, there is only a small stack frame.

The memory usage of Sat increases significantly with \(\lambda \) and the overhead is more than for ItD: this is because of the large, explicitly-stated SAT formulas and the use of a general-purpose SAT solver.

For small \(\kappa \), Fpt uses less memory than Sat due to the latter’s overhead. However, Fpt clearly uses the most memory as \(\kappa \) increases, since it quite fundamentally relies on the memoization of a large recurrence. Its memory usage in fact limits the number of characters that can be supported – in practice by the available memory, but even more generally by the memory architecture of normal environments.

Table 2. Memory usage in MB on uniform random instances (\(p=0.5\)) with 100 meetings and a variable number of characters \(\kappa \). Only Sat’s memory usage varies considerably over different instances with the same number of characters.

Concluding Remarks. We conclude with some practical advice about picking an algorithm. The first consideration is a hard constraint: if concurrent meetings are required, ItD and Fpt are disqualified and Sat remains as a fine default. We now assume concurrent meetings are not required.

If the number of characters is small, the use of Fpt is clearly preferred. This algorithm can truly be considered fixed-parameter tractable in the number of characters \(\kappa \). However, the dependence on \(\kappa \) includes factorial space, which makes it impractical to run the algorithm on personal computers beyond \(\kappa =10\) and impossible to run at all for even a few characters more than that. Many real-world instances have too many characters for Fpt.

The runtime of both ItD and Sat depends heavily on the number of block crossings in the optimum. For very small optimum, ItD can be faster, but only if the number of characters is also quite small: there is still the branching factor of \(\kappa !\). If memory is a problem and the optimum is small, then ItD is an option, but in general Sat is vastly preferable.

As a final remark, we note that all these implementations are single-threaded, and as such achieve only “25%” utilization on our quad-core test machine. ItD could be trivially parallelized by dividing the search space; Fpt is trickier to parallelize from an engineering perspective. It would be possible to use a parallelized SAT solver, like PMSat [7] or HordeSAT [1]. However, it is not clear a priori how effective those would be for our specific SAT formulas.

4 Conclusion

In this paper we have presented a SAT-based algorithm for computing block-crossing optimal storyline visualizations and extensive experimentation on random instances. We have demonstrated that on some real-world instances (in particular, the movies), Sat has runtime similar to the ILP of Gronemann et al., who optimize pairwise crossings. For other instances (the books), Sat fares poorly. We have also evaluated implementations of two further algorithms for storyline block crossing optimization.

For future work, it would be interesting to perform further algorithm engineering on Sat. In particular, it may be possible to handle the birth/death of characters more efficiently or to better integrate with SAT algorithms.

In a different direction, one might use an ILP solver on a model very similar to that of Sect. 2. This would, for example, enable us to minimize the number of pairwise crossings subject to the number of block crossings being optimal. However, preliminary experiments showed very poor performance.

From a graphic design perspective, optimizing for block crossings intuitively makes sense. However, we are not aware of any user studies that investigated whether block crossings are good, and what the trade-offs are. For example, is a \(4 \times 4\) block crossing equally bad as a \(2 \times 8\) block crossing?

Notes

  1. 1.

    For example, Gandalf meets Éomer while the host of elves arrives at Helm’s Deep. In the movie, we learn about this only afterward; Munroe’s visualization of The Lord of the Rings [12] makes clear that this is concurrent.

  2. 2.

    http://www1.pub.informatik.uni-wuerzburg.de/pub/data/storylines/.

  3. 3.

    This concept of meeting groups is similar to the trees constructed by Gronemann et al. [8] to generate MLCM-TC instances.

  4. 4.

    Slightly modified to measure peak memory usage on Windows.

References

  1. Balyo, T., Sanders, P., Sinz, C.: HordeSat: a massively parallel portfolio SAT solver. In: Heule, M., Weaver, S. (eds.) SAT 2015. LNCS, vol. 9340, pp. 156–172. Springer, Cham (2015). https://doi.org/10.1007/978-3-319-24318-4_12

    CrossRef  Google Scholar 

  2. Bekos, M.A., Kaufmann, M., Zielke, C.: The book embedding problem from a SAT-solving perspective. In: Di Giacomo, E., Lubiw, A. (eds.) GD 2015. LNCS, vol. 9411, pp. 125–138. Springer, Cham (2015). https://doi.org/10.1007/978-3-319-27261-0_11

    CrossRef  Google Scholar 

  3. van Dijk, T.C., Fink, M., Fischer, N., Lipp, F., Markfelder, P., Ravsky, A., Suri, S., Wolff, A.: Block crossings in storyline visualizations. J. Graph Algorithms Appl. 21(5), 873–913 (2017). https://doi.org/10.7155/jgaa.00443

    CrossRef  MATH  Google Scholar 

  4. van Dijk, T.C., Lipp, F., Markfelder, P., Wolff, A.: Computing storyline visualizations with few block crossings. arXiv report http://arxiv.org/abs/1709.01055 (2017)

  5. Eén, N., Mishchenko, A., Sörensson, N.: Applying logic synthesis for speeding up SAT. In: Marques-Silva, J., Sakallah, K.A. (eds.) SAT 2007. LNCS, vol. 4501, pp. 272–286. Springer, Heidelberg (2007). https://doi.org/10.1007/978-3-540-72788-0_26

    CrossRef  Google Scholar 

  6. Eén, N., Sörensson, N.: MiniSat SAT solver (2003). http://minisat.se

  7. Gil, L., Flores, P., Silveira, L.M.: PMSat: a parallel version of MiniSAT. J. Satisf. Bool. Model. Comput. 6, 71–98 (2008). https://satassociation.org/jsat/index.php/jsat/article/view/70

    MathSciNet  MATH  Google Scholar 

  8. Gronemann, M., Jünger, M., Liers, F., Mambelli, F.: Crossing minimization in storyline visualization. In: Hu, Y., Nöllenburg, M. (eds.) GD 2016. LNCS, vol. 9801, pp. 367–381. Springer, Cham (2016). https://doi.org/10.1007/978-3-319-50106-2_29

    CrossRef  Google Scholar 

  9. Kim, N.W., Card, S.K., Heer, J.: Tracing genealogical data with TimeNets. In: Proceedings of the International Conference on Advanced Visual Interfaces (AVI 2010), pp. 241–248 (2010). https://doi.org/10.1145/1842993.1843035

  10. Knuth, D.E.: The Art of Computer Programming, Volume 3: Sorting and Searching, 2nd edn. Addison Wesley Longman Publishing Co., Inc., Redwood City (1998)

    Google Scholar 

  11. Kostitsyna, I., Nöllenburg, M., Polishchuk, V., Schulz, A., Strash, D.: On minimizing crossings in storyline visualizations. In: Di Giacomo, E., Lubiw, A. (eds.) GD 2015. LNCS, vol. 9411, pp. 192–198. Springer, Cham (2015). https://doi.org/10.1007/978-3-319-27261-0_16

    CrossRef  Google Scholar 

  12. Munroe, R.: Movie narrative charts (2009). https://xkcd.com/657/. Accessed 16 Feb 2017

  13. Tanahashi, Y., Ma, K.: Design considerations for optimizing storyline visualizations. IEEE Trans. Vis. Comput. Graph. 18(12), 2679–2688 (2012). https://doi.org/10.1109/TVCG.2012.212

    CrossRef  Google Scholar 

  14. Wertheimer, M.: Untersuchungen zur Lehre von der Gestalt. II. Psychologische Forschung 4(1), 301–350 (1923)

    CrossRef  Google Scholar 

Download references

Acknowledgments

We thank Martin Gronemann for providing the input files used in the experiments of [8].

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Fabian Lipp .

Editor information

Editors and Affiliations

Rights and permissions

Reprints and Permissions

Copyright information

© 2018 Springer International Publishing AG

About this paper

Verify currency and authenticity via CrossMark

Cite this paper

van Dijk, T.C., Lipp, F., Markfelder, P., Wolff, A. (2018). Computing Storyline Visualizations with Few Block Crossings. In: Frati, F., Ma, KL. (eds) Graph Drawing and Network Visualization. GD 2017. Lecture Notes in Computer Science(), vol 10692. Springer, Cham. https://doi.org/10.1007/978-3-319-73915-1_29

Download citation

  • DOI: https://doi.org/10.1007/978-3-319-73915-1_29

  • Published:

  • Publisher Name: Springer, Cham

  • Print ISBN: 978-3-319-73914-4

  • Online ISBN: 978-3-319-73915-1

  • eBook Packages: Computer ScienceComputer Science (R0)