Transcript Streaming Meshes Martin Isenburg Peter Lindstrom UC Berkeley LLNL Indexed Formats # # # # # v v v v triceratops.obj 3.661 3.719 3.977 4.077 f f f f 27972783 2832 vertices 2834 polygons ⋮ ⋮ 0.002 0.347 0.311 0.139 ⋮ 28012794 ⋮ ⋮ -0.738 -0.833 -0.725 -0.654 ⋮ 2815 2821 2811 2805 2802 2796 ⋮ ⋮

Streaming Meshes
Martin Isenburg
Peter Lindstrom
UC Berkeley
LLNL
Indexed Formats
#
#
#
#
#
v
v
v
v
triceratops.obj
3.661
3.719
3.977
4.077
f
f
f
f
2806
2797
2789
2783
2832 vertices
2834 polygons
⋮
⋮
0.002
0.347
0.311
0.139
⋮
2810
2801
2793
2794
⋮
⋮
-0.738
-0.833
-0.725
-0.654
⋮
2815 2821
2811 2805
2802 2796
2788
⋮
⋮
Original Orderings
showing the first 20
to 40 percent of the
triangle array
Large Meshes
3D scans
isosurfaces
Large Meshes
3D scans
isosurfaces
Input Problem
Indexed Mesh
Mesh Pieces
186 million
vertices
= 2 GB
372 million
triangles
= 4 GB
6 GB
6.1 GB
Input Problem
Indexed Mesh
External Memory Mesh
186 million
vertices
= 2 GB
372 million
triangles
= 4 GB
6 GB
12 GB
Input Problem
Indexed Mesh
Triangle Soup
186 million
vertices
= 2 GB
372 million
triangles
= 4 GB
6 GB
12 GB
Papers from 1997 - 2005
• Viz 1997, “I/O Optimal Isosurface Extraction”, Chiang, Silva
“unfortunately, data sets are often given in formats that contain indices to vertices”
• SIGGRAPH 2000, “Out-of-Core Simplification”, Lindstrom
“operate on a triangle soup in which each triangle”
• SIAM 2003, “Adaptive Vertex Clustering”, Schaefer, Warren
“we also assume that the mesh is in a triangle soup format”
• GI 2003, “Decimation of Massive Meshes”, Wu, Kobbelt
“in this format (dubbed “triangle soup” in [14]) every triangle”
• TVCG 2003, “External Memory Mesh”, Cignoni et al.
“from a triangle soup (list of faces, not indexed)”
• SIGGRAPH 2004, “Tetra Puzzles”, Cignoni et al.,
“we assume […] triangle soup, a flat list of triangles”
• SIGGRAPH 2005, “Far Voxels”, Gobbetti, Marton
“[…] we assume […] represented as a triangle soup”
Large Model Distribution
“Digital Michelangelo Project”
Stanford University
“3D Gallery”
Visual Computing Lab, ISTI
Reading Indexed Input
• one-pass
– memory-map the vertex array
– rely on paging system of OS
– will “fail” on incoherent input
• multi-pass [Chiang & Silva 1997]
– sort triangle array on each index field
– replace index with vertex
– large disk space and I/O overhead
Output Problem
Pieces
Indexed
186 million
vertices
= 2 GB
372 million
triangles
= 4 GB
Writing Indexed Output
• use computer with lots of memory
– Stanford used an SGI Onyx2
• output piece by piece
– concatenate in final pass
• memory-map the mesh
– number of vertices known a priori ?
• output into two separate files
– concatenate in final pass
Format Conversion
possibly not IO-efficient
+ finalization !!!
standard indexed formats
pieces
external
soup
186 million
vertices
= 2 GB
372 million
triangles
= 4 GB
IO-efficient
streaming formats
Streaming Formats
Streaming Formats
• physical
– water in a pipe
– drip coffee
• digital
– streaming formats
• audio
• video
• geometry
Two Types of Streaming
• progressive





• non-progressive

Non-Progressive Streaming
• consume immediately
• potentially without end
• keep small buffer
• delete data if no longer needed
small window
Streaming Mesh Formats
v 1.32
v 1.43
v 0.91
f 1 2
finalize
v 0.72
f 4 1
finalize
⋮ ⋮
0.12
0.23
0.15
3
2
0.34
3
1
⋮
0.23
0.92
0.62
vertex # 2
introduced
not used by
preceding
triangles
active
0.35
⋮
interleave
vertex # 2
finalized
introduce
not used by
subsequent
triangles
finalize
Reading Streaming Formats
mesh.open ( “mesh.sma” );
while ( event = mesh.read_event() )
switch ( event )
case TRIANGLE:
// look-up v[0], v[1], v[2] in hash
case VERTEX:
// put new vertex in hash
case FINALIZE:
// remove finalized vertex from hash
mesh.close ();
Streaming Mesh Definitions
• width
– maximal number of active vertices
 how many vertices need to be buffered
• span
– maximal “time” a vertex stays active
 how “long” vertices remain in the buffer
• do not “bloat” width and span !!!
– introduce late and finalize early
Writing Streaming Formats
• isosurface
– 235 million vertices
– 469 million triangles
over
8 Gigabyte
• marching cubes
– extract layer by layer
– output elements as extracted
– finalize vertices of previous layer
Richtmeyer-Meshkov instability simulation at LLNL
Coherence in Indexed Meshes
Streaming
Layout Diagram
triangles
vertices
Indexed
triangle spans
vertex spans
 visualization of the
coherence
 tells us how difficult it
is to convert to stream
Layout Diagram: Buddha
vertices
triangles
20 MB
Layout Diagram: Dragon
vertices
triangles
20 MB
Layout Diagram: Lucy
vertices
triangles
508 MB
Layout Diagram: St. Matthew
vertices
triangles
vertex span
6,760 MB
676 MB
338 MB
Visualizing high vertex spans
Topologic and Geometric Sort
depth-first
breadth-first
z-order
along one axis
Output Qualities
• low width & low span
– sweep-line
– FIFO (queue)
• low width, high span
– block by block
– FILO (stack)
• high width, high span
– random access
Streaming with minimal width
• graph theory
– minimization is NP hard
– heuristic: “spectral sequencing”
Stream-Processing
Stream-Processing Model
processed
region
in-core
buffer
unprocessed region
Stream-Processing Tasks
• tasks that process mesh elements
one at a time
– e.g. for each triangle t …
• tasks that only require access to
local neighbors
– e.g. for each triangle t of vertex v …
• tasks that are order independent
– e.g. collapse edges shorter than 
Streaming Simplification
“A Stream Algorithm for … ”
[Wu & Kobbelt ‘03]
“Large Mesh Simplification …”
[Isenburg et al. ‘03]
Performance
compared to:
“External Memory Management and Simplification of
Huge Meshes”
[Cignoni et al. ‘03]
construct
simplify
Octree-based External Memory Mesh
(figure courtesy of Paolo Cignoni)
11 hrs
12 GB
14 hrs
45 min
80 MB
15 MB
Streaming Compression
“Streaming Compression of Triangle Meshes”
[Isenburg, Lindstrom & Snoeyink ‘05]
Performance
compared to:
“Out-of-Core Compression of Gigantic Polygon
Meshes”
[Isenburg & Gumhold ‘03]
construct
compress
file size
Out-of-Core Mesh
7 hrs
11 GB
4 hrs
28 min
384 MB
12 MB
344 MB
392 MB
Pipelined Streaming
Pipelined Stream-Processing
• conventional processing
P1
P2
P3
• pipelined stream-processing
P1
P2
P3
P1
P2
P3
– super-linear speedup
– minimal end-to-end I/O delay
– optimal disk caching
Demo Pipeline
regular volume grid
v 1.32 0.12
v 1.43 0.23
v 0.91 0.15
f 1 2 3
finalized 2
v 0.72 0.34
f 4 1 3
finalized 1
⋮ ⋮ ⋮
256
256
0.23
0.92
0.62
0.35
⋮
256
smextract | smclean | smsimp | smcompress
P1
grid.raw
P2
P3
P4
mesh.smc
Conclusion
Indexed Formats do not Scale
1 MB
9 GB
Small Change … Big Benefits
Standard Format
Streaming Formats
Current / Future Work
• more stream modules
– streaming re-meshing
– streaming smoothing
– streaming feature extraction
– streaming stripification, …
• stream other geometry data
– volumetric meshes / grids
– points in 2D and 3D
Streaming Volume Meshes
• format
– like surface mesh format
– straight-forward
• applications
– streaming iso-surface extraction
– streaming simplification
– streaming compression
– streaming mesh refinement, …
Volume Mesh Compression
compared to:
torso
“Tetrahedral Mesh Compression
with the Cut-Border Machine”
[Gumhold et al. ‘99]
fighter
compress
bits / tet
662 sec
12 sec
140 MB
6 MB
1.81
3.56
Layouts of Volume Meshes
torso.off
v = 168,930
tet = 1,082,723
(19 MB)
fighter.off
v = 256,614
tet = 1,403,504
(25 MB)
rbl.off
v = 730,273
tet = 3,886,728
(70 MB)
Streaming Points
• format
– need “spatial finalization”
• e.g. no future points in this “space”
• applications
– streaming surface reconstruction
– streaming re-sampling
– streaming smooting
– streaming compression, …
Streaming Delaunay
2D Delaunay
2D Delaunay triangulate
6 million terrain points
3D Delaunay
250 sec
125 sec
450 MB
4 MB
Acknowledgements
• meshes
– Stanford University
– Cyberware
• support
– NSF grant 0429901
"Collaborative Research: Fundamentals
and Algorithms for Streaming Meshes."
– U.S. DOE / LLNL # W-7405-Eng-48
Thank You
Which models have such layouts?
Why?
Read the paper!
demo & API :
http://www.cs.unc.edu/~isenburg/sm