XFastMesh Fast View-dependent Meshing from External Memory

1
XFastMeshFast View-dependent Meshing from
External Memory
Christopher DeCoro Renato B. Pajarola
cdecoro_at_cat.nyu.edu http//www.cat.nyu.edu/cdecor
o/ Center for Advanced Technology Courant
Institute of Mathematical Sciences New York
University pajarola_at_ics.uci.edu http//www.ics.uc
i.edu/graphics/ Computer Graphics Lab Dept. of
Information Computer Science University of
California Irvine
2
Talk Outline

• Introduction
• Motivation and applications
• Related work
• Background
• External-memory structure
• Main-memory structure
• Experimental results
• Future work

3
Motivation

• Huge geometric models
• Digital 3D scanners
• Digital Michelangelo's David, 8M triangles
• CAD, scientific visualization, GIS
• Limited rendering performance
• Graphics hardware accelerators can render a fixed
  amount of triangles in real-time
• We can acquire huge models that far exceed the
  capability of graphics cards in the foreseeable
  future
• Limited memory size
• Current models can require more storage than we
  can afford to spend (or want to spend)
• Multiresolution formats require additional space

4
Related Work

• View-dependent mesh simplification
• binary vertex trees Xia et al. 96 and Hoppe
  97
• multi-triangulation DeFloriani et a. 98
• vertex clustering hierarchies Luebke Erikson
  97 and Schmalstieg Schaufler 97
• FastMesh Pajarola 01
• External-memory mesh simplification
• El-Sana and Chiang 2001
• Prince 2000

5
Background - Half-edges
B
B
A
Edge collapse
A
b
b
a
a
h.n.v
h
h
h.v
Vertex split
c
d
d
D
D
c
C
C

• Represents mesh and simplification operations
  with half-edges and edge collapses / vertex
  splits
• Three consecutive half-edges form a triangle
• Each half-edge stores its reverse half-edge, and
  starting vertex
• Half-edges allow for efficient local mesh update
• Each vertex split introduces 1 vertex and 2
  triangle faces

6
Background -Multiresolution Hierarchy
expanded vertex splits
collapsed edges and faces
Half-edge collapse hierarchy

• Uses a hierarchy of half-edge-collapse operations
• Each node corresponds to a split/collapse
• Level of detail represented as front through
  hierarchy
• Detail increases as the front descends the tree

7
Background - Basic Simplification Criteria

• Out-of-frustum Simplification
• Back-face Simplification

8
Background Heuristic Simplification Criteria

• Screen-projection Simplification
• Normal-angle Deviation
• Silhouette Preservation

9
Background - LOD parameters

• Bounding spheres
• minimal sphere enclosing all affected triangles
  (vertices) and spheres of child nodes

10
Background - LOD parameters

• Bounding spheres
• minimal sphere enclosing all affected triangles
  (vertices) and spheres of child nodes
• Bounding normal cones
• minimal bounding cone around vertex normal
  enclosing all normal directions of subtree

11
Talk Outline

• Introduction
• External-memory structure
• Overview
• Initial mesh
• Detail blocks
• Auxiliary data
• Data file construction
• Main-memory structure
• Experimental results
• Future work

12
External Memory Structure Overview

• Base mesh stored as-is in external storage
• Loaded at run-time, kept resident during
  execution
• Detail stored as discrete blocks
• Similar in structure to a B-tree (high-degree
  nodes)
• Links within a block represented implicitly
• All faces/vertices/half-edges given unique ID
• ID is used to determine the block number
• Block number is used to determine disk location

13
Detail blocks

• Edge-collapse trees are divided into blocks
• Assumes full subtrees
• Forms block tree
• High-degree nodes, similar to B-tree
• Blocks efficiently encode detail
• Intra-block links represented implicitly

14
Detail blocks Geometry

• Form disc-like regions on the surface
• Therefore, block nodes are located spatially
  close together
• Similar positions and orientation
• Lower level blocks form smaller disks
• Parent discs (left) encompass child discs (right)

15
Detail Blocks - Contents

• Information is stored for each existing node
• Vertex, normal coordinates
• Bounding sphere radius, bounding cone angle
• Global ordering
• Used for fold-over prevention
• Four Adjacent half-edges
• Connectivity used to place new edges into mesh
• Stores connectivity to other blocks
• ID of parent node (locates block and node)
• ID of all child nodes
• Flags
• Indicates number of nodes present

16
Detail Blocks - Packing

• High-degree trees will have many leaves
• As blocks store complete subtrees, leaf blocks
  will be non-full
• Leaf blocks do not need child pointers
• Blocks are packed to remove wasted space
• Only nodes that exist are stored in block
• Flags indicate which blocks are available
• Maintains complete subtree structure
• Child pointers stored only for non-leaf nodes
• Also indicated by flag

17
Auxiliary Data

• Header
• Fixed sized header indicating locations of other
  fields
• Initial Mesh
• Base mesh M0 stored explicitly on disk, loaded at
  start time
• Block Index
• For given block b, stores disk offset of b
• Required because packing scheme results in blocks
  with varying sizes
• Index itself can be entirely loaded at startup,
  or accessed through memory-mapping
• Root Block List
• Lists which blocks contain root nodes of the
  hierarchy
• Root blocks are loaded at start time and kept
  resident

18
Talk Outline

• Introduction
• External-memory structure
• Main-memory structure
• Overview
• Block loading
• Block deletion
• Experimental results
• Future work

19
Main-memory Structure - Overview

• Block Directory
• Points to all loaded blocks
• Similar to a page table
• High bits of ID represent block
• Low bits of ID represents offset in block
• Time Priority Queue
• Min-queue that stores blocks by least recently
  used
• Used for caching blocks

20
Tree Node

• Mesh
• Stores additional vertex, normal coordinates
• Six half-edges, representing two faces introduced
  by split
• Trees
• Links to merge tree nodes
• Links to block tree nodes
• Timestamp
• Simplification parameters

21
Block Loading

• Case 1 Front moves below frontier of loaded
  blocks
• Frontier lowest point in the hierarchy for which
  blocks are loaded
• Given block ID, lookup disk address in block
  index, read from disk
• Inflate block from disk format enter into
  directory, attach to tree

22
Block Loading

• Case 2 Forced split requires load of arbitrary
  block
• Update operations that can be required to
  maintain mesh
• results from edge collapses
• From split edge ID, determine block ID read
  block
• Use parent ID to load parent block
• Repeat until all blocks are connected into the
  hierarchy

23
Block Deletion

• Caching is required for acceptable performance
• Once user-specified quota is reached, blocks will
  be deleted
• Least-recently-used blocks are removed first
• Marked as unused when front moves above root node
  of block
• Maintains a priority-queue to determine LRU blocks

24
Talk outline

• Introduction
• External-memory structure
• Main-memory structure
• Experimental results
• Storage cost
• Run-time performance
• Examples
• Future work

25
Storage cost

• Cost of data file measured on disk
• Less than 30 bytes/tri
• Compares to our original format (about equal)
• More efficient than previous external methods

26
Run-time performance
Sun 450MHz UltraSPARC-II CPU, Expert3D PCI
graphics

• Results shown are average time per frame
• Block load time is generally dominated by
  rendering
• Block load time also tends to be much less than
  the view-dependent operations
• Through caching, load time tends to decrease as a
  percentage of frame over time

27
More examples

• Upper row displays view from users perspective
• Lower row shows same image from outside view
  (represented as yellow pyramid)
• Threshold adjusted to achieve constant 5 frames /
  second
• Between 50 K 67 K triangles per frame

28
Animated example
29
Future work

• Out-of-core Preprocess
• Would allow more flexibility in creating models
• Asynchronous disk access
• Parrallelize time spent reading from disk
• Pre-fetch
• One solution could be based on predicting path of
  camera movement
• Another could base prefetching based on rate of
  change in the front
• Geometry Compression
• Allows more information transferred through disk
  bottleneck
• Tradeoff between processor speed vs. disk
  speed/storage

30
Conclusion

• Straight-forward approach to external-memory
  meshing can be successful, if implemented
  efficiently
• Hierarchy broken into blocks
• Minimal transformations to hierarchy required
• Synchronous disk access
• Disk access overhead, when blocks are cached, can
  be minimized
• Synchronous access does not present excessive
  overhead
• History-based Caching
• Least-recently used caching scheme dramatically
  reduces disk accesses
• No need to attempt prediction of detail required
  in upcoming frames