View
213
Download
1
Category
Preview:
Citation preview
Composite Rectilinear Deformation for Stretch and Squish Navigation
James Slack, Tamara Munzner
University of British ColumbiaNovember 1, 2006
Imager
2
Composite Rectilinear Deformation
Stretch and squish navigation• User selects any region to grow or shrink• Visual history of navigation• Simultaneous region resizing
Growing a region
3
Successive Navigations Preserve History
Stretch and squish navigation composes deformations temporally• Navigation in regions affects entire view• Effects of all previous navigations persist
4
Is Stretch and Squish Navigation Hard?
Simple to use Underlying infrastructure is complex to implement
• Standard graphics pipeline has a single, monolithic transformation• Mathematical composition of multiple transformations
• Stretch and squish cannot be implemented using this pipeline
5
Related Work
Stretch and squish navigation• Scales only to hundreds of objects
• Rubber-sheet navigation (Sarkar 1992)• Document Lens, single region deformation (Robertson 1993)
General deformable surfaces• Scales only to thousands of objects
• Non-linear magnification (Keahey 1997)• Pliable surfaces (Carpendale 1995)
Scalable visualization supporting millions of objects• No stretch and squish navigation techniques
• MillionVis (Fekete 2002)• Tulip (Auber 2003)
6
Related Work
Accordion Drawing Systems• Previous stretch and squish work focused on drawing• Assumed navigation algorithms existed, and never described
• TreeJuxtaposer (Munzner 2003)• SequenceJuxtaposer (Slack 2004)• PRISAD (Slack 2005)
7
Contributions
Our contribution: an algorithm for stretch and squish navigation• Use PRISAD for drawing dataset objects• Scale to millions of dataset items• Not dataset-specific, a generic infrastructure for navigation• Visually composable
• All previous actions visible• Deformations are lossless
• Support for localized deformation
8
Complexity of Drawing
PRISAD rendering reduced the drawing complexity by culling• For each frame: draw representative visible subset, not entire dataset• (Total number of drawn objects per frame) << (Total dataset items)
• In tree dataset with 600,000 leaves, draw only 1000 leaves• In sequence datasets, aggregate dense regions in software
1000 leaves visible Dense, culled regions
9
Complexity of Navigation
PRISAD drawing complexity is in terms of visible objects• Draw objects at certain visible threshold
Navigation complexity determined by work done per animation frame Navigation actions stretch and squish many objects simultaneously Our algorithm update complexity is relative to regions that change
• Number of regions to change simultaneously is limited• Grow just a few regions at once, dozens would be confusing!
• Growing a region should not require updating every object• (Updates for navigation) << (Total dataset objects)
10
Grids and Regions
Stretch and squish a rectilinear grid, deform to navigate• PRISAD uses grid to render, layout, etc.• Normally not visible to end user
Atomic region: smallest navigation granularity Composite region: collection of many atomic regions
• User moves outer region boundaries, interior grid lines follow
Atomic Region Composite Region
11
Grid = Pair of Line Sets
Separate horizontal and vertical line sets• Navigate simultaneously, independently in both sets
Use same navigation algorithm for both sets
Horizontal line set
Vertical line set
12
Moving in a Set of Lines
Navigation in a line set moves small number of lines Suppose 1,000,000 lines in horizontal line set
Only 1000 of these lines are used by PRISAD for drawing given frame• Visible regions between pairs of lines large enough to draw
Move small number of lines marked in red to new locations• Boundaries of composite regions• Not necessarily a subset of visible region boundaries
13
Usage Scenario: Expand 3 Regions
3 composite regions marked by user to grow vertically• 3 vertical regions to grow = 6 line boundaries to move
• No horizontal navigation in this example
Grow 3 regions vertically
14
Moving Lines
A navigation may change many grid line positions
Every grid line potentially moves in a single navigation
Updating every grid line would be too expensive• To avoid linear update cost, we introduce a hierarchy
15
Split Line Hierarchy Subdivision
We build a balanced binary hierarchy from each line set• Called split line hierarchy, also used for PRISAD rendering
Entire horizontal line set
Entire horizontal line set
Smaller example
Central line
Children of central line
Deeper regions of hierarchy
16
Split Lines
Split lines order grid lines hierarchically• Split lines are positioned between 2 split lines in the hierarchy
• Central split line bounded by scene boundaries• Split lines are bounded by parents
• E.g. C is bounded by B and D
17
Split Line Position versus Ratio
Each split line has an on-screen position
We store ratios for each split line• Ratio is relative distance of a split line between its bounds
0.0 0.3 0.5 0.7 1.0
0.0 0.3 0.5 0.7 1.0
0.60.5
0.4
Positions
Ratios
18
From Ratio to Position
Ratios store positions indirectly with respect to ancestor positions• Position = (left bound) + (ratio) x (right bound – left bound)• 0.7 = 0.5 + 0.4 x (1.0 – 0.5)
Positions can be computed in logarithmic time: ancestors in hierarchy• Positions computed only on demand, not for all objects• We may cache positions during one animation frame
0.0 0.3 0.5 0.7 1.0
0.60.5
0.4
Positions
Ratios
19
Navigation Algorithm Complexity
Input: set K of split lines with final positions
• Only identity and positions of red lines required for input
Output: set Q of split lines with final ratios
• Algorithm determines which additional lines require a new ratio• Changing ratios of these lines to output values will move K split lines
• All relative positions between red lines are preserved
20
Running Example of a Navigation
Total number of split lines: 1023 Selected split lines to move: 4 Input to algorithm:
K (indices)position
ratio
63 191 255 639
0.3 0.4 0.6 0.9
final position 0.2 0.5 0.6 0.7
21
Navigation Algorithm
Flow of our navigation algorithm:
moveSplitLines
resize
partition
interpolate
getRatio
Initialize
RecurseRecurse
22
Algorithm: moveSplitLines
Initialize split line set that user wishes to move• M = split line list: input from user, plus left and right bounds• S = split line for partition: root split line (index 511), exact middle• Q = output ratios list: { }
moveSplitLines Initialize
M (indices)
position
ratio
63 191 255 639
0.3 0.4 0.6 0.9
final position 0.2 0.5 0.6 0.7
00.0
0.0
1022
1.01.0
23
Navigation Algorithm: resize
moveSplitLines
resize
partition
interpolate
getRatio
Initialize
RecurseRecurse
24
Navigation Algorithm: partition
moveSplitLines
resize
partition
interpolate
getRatio
Initialize
RecurseRecurse
25
Algorithm: partition
Partitions set M according to location of S S = 511, between 255 and 639
partition
M (indices)position
ratio
63 191 255 639
0.3 0.4 0.6 0.9
final position 0.2 0.5 0.6 0.7
0
0.00.0
1023
1.01.0
S = 511
26
Algorithm: partition output
Partition returns L and R:
initial position (i)
ratio
63 191 255 511
0.3 0.4 0.6 0.7
final position (f) 0.2 0.5 0.6
0
0.0
0.0
639 1023
0.9 1.0
1.0
511
0.7
index
0.7
Left (L) Right (R)
??
SS
27
Navigation Algorithm: interpolate
moveSplitLines
resize
partition
interpolate
getRatio
Initialize
RecurseRecurse
28
Algorithm: interpolate
Interpolate determines the final position of S (index 511)• Since S must be between 255 and 639 with same ratio:
• f[S] = f[left] + (f[right] – f[left]) * (i[S] – i[left]) / (i[right] – i[left])= f[255] + (f[639] – f[255]) * (i[511] – i[255]) / (i[639] –
i[255])
= 0.6 + (0.7 – 0.6) * (0.7 – 0.6) / (0.9 – 0.6) = 0.63
position (i)
ratio
63 191 255 511
0.3 0.4 0.6 0.7
final position (f) 0.2 0.5 0.6
0
0.0
0.0
639 1023
0.9 1.0
1.0
511
0.7
index
0.7
Left Right
??
S S
0.63 0.63
29
Navigation Algorithm: getRatio
moveSplitLines
resize
partition
interpolate
getRatio
Initialize
RecurseRecurse
30
Algorithm: getRatio
Finally, compute ratio for S with new final position for S• Ratio S = Final 0 + (Final 511 – Final 0) / (Final 1023 – Final 0)
= 0.0 + (0.63 – 0.0) / (1.0 – 0.0)
= 0.63• Add S to Q
Position (I)
ratio
56 73 300 511
0.3 0.4 0.6 0.7
0.63
final position (F) 0.2 0.5 0.6
0
0.0
0.0
754 1023
0.9 1.0
1.0
511
0.7
0.63
index
0.7
Left Right
0.630.63
Q: 511
0.63
index
ratio
S S
31
Navigation Algorithm
moveSplitLines
resize
partition
interpolate
getRatio
Initialize
RecurseRecurse
32
Recursion
Each recursion step computes one split line ratio
Algorithm termination: when a partition contains no more lines to move• When M=2, bounds of S have computed positions and ratios
M (indices)position
ratio
639
0.9
0.7final position
0.32
511
0.7
0.630.63
Q: index
ratio
511
0.63
255
0.95
127
0.43
63
0.77
191
0.71
767
0.59
639
0.32
33
Result: Algorithm Complexity
Logarithmic complexity: |Q| |K| log |N| << |N|• Q: Lines needing ratio updates• K: Lines to move• N: All lines
Many positions change, but few ratios require updates• Moving 2 grid lines only requires changing ratios for 8 split lines• Subtrees not affected will conserve their internal ratios
34
Results: Implementation
Speed: under 1 millisecond for |N| = 2,000,000 lines Generality: implemented in PRISAD infrastructure as proof of concept
• Tree, sequence dataset visualizations
35
Algorithm provides lightweight visual history
Algorithm supports localized deformations• Set final positions for local bounds to start positions
Results: Design Goals Met
Localizing boundaries
36
Future Work
Implement stretch and squish navigation in other architectures
Support non-rectilinear deformations• Localizing regions may assist in reducing complexity
37
Conclusions
First scalable algorithm for stretch and squish navigation• K log N performance to move K of N lines
Infrastructure for composite rectilinear navigations• Lightweight visual history• Move several region boundaries simultaneously• Localized deformation• Shown on trees and gene sequences
38
Acknowledgements
InfoVis group at UBC:
Ciarán Llachlan Leavitt
Dan Archambault
Aaron Barsky
Stephen Ingram
Heidi Lam
Peter McLachlan
Melanie Tory
39
Download Software
http://olduvai.sf.net/tj
Recommended