Title: Accelerations and Scene Graphs
1Accelerations and Scene Graphs
Partially Adapted From David Luebkes course notes
2Motivation
- VR scenes need complexity
- Immersion
- People dont bother with VR for easy problems
- lots of geometry
- How do we maintain speed?
- Wait for the graphics cards?
3Problem
- Much of OpenGL is immediate mode and state based
- glBindTexture (GL_TEXTURE_2D, 13)glBegin
(GL_QUADS)glTexCoord2f (0.0, 0.0)glVertex3f
(0.0, 0.0, 0.0)glTexCoord2f (1.0,
0.0)glVertex3f (10.0, 0.0, 0.0)glTexCoord2f
(1.0, 1.0)glVertex3f (10.0, 10.0,
0.0)glTexCoord2f (0.0, 1.0)glVertex3f (0.0,
10.0, 0.0)glEnd ()
4Limitations of Immediate Mode Graphics
- When we define a geometric object in an
application, upon execution of the code the
object is passed through the pipeline - It then disappears from the graphical system
- To redraw the object, either changed or the same,
we must reexecute the code - Display lists provide only a partial solution to
this problem
5The Scene Graph
- Build up a structure that allows
- more intuitive modeling
- global analysis of the model
- generate OpenGL calls in an efficient way
- CPU-level preprocessing to avoid overloading
graphics pipeline
6Scene Graphs
- Datastructure Directed Acyclic Graph (DAG)
- Usually a tree (only one parent per node)
- Represents object-based hierarchy of geometry
- Leaves contains geometry (triangles, etc.)
- Each node holds pointers to children
- Children can be
- Group
- Geometry
- Matrix transform
- Others
7Scene Graphs
- Spatial transforms represented as graph nodes
(rotation, translation, scaling, etc.)
tricycle
T
T
Seat
Front Group
Back wheels
Handle bars
Left wheel
Right wheel
T
Front Wheel
8Transforms in the Scene Graph
- Put a transform in each internal node
- Gives instancing, and hierarchical animation
9Scene GraphsState Changes
- State changes affect the way the graphics
pipeline execute - A change in state may require
- flushing the pipeline
- flushing the cache (on the graphics card)
- Binding to a texture is one of the most expensive
state changes
10Scene GraphsState Changes
- Scene graphs are used for state sorting
- State information is stored with the nodes
- Optimized rendering algorithms take advantage of
groupings of same-state primitives - Scene graph hierarchy can be (algorithmically)
rearranged for rendering into a state graph - State tends to be static
11How Else Can SGs Help?
- What are some ways the graphics pipeline speeds
rendering? The basic idea dont render what
cant be seen - Off-screen geometry solved by clipping
- Occluded geometry solved by Z-buffer
- Clipping and Z-buffering take time linear to the
number of primitives - How can SGs help?
- Off-screen view-frustum culling
- Occluded by other objects occlusion culling,
backface culling
12View Frustum Culling Goal
- Quickly eliminate large portions of the scene
which will not be visible in the final image - Not the exact visibility solution, but a
quick-and-dirty conservative estimate of which
primitives might be visible - Z-buffer clip this for the exact solution
- This conservative estimate is called the
potentially visible set or PVS
13View-Frustum Culling
- An old idea (Clark 76)
- Organize primitives into clumps
- Before rendering the primitives in a clump, test
a bounding volume against the view frustum - If the clump is entirely outside the view
frustum, dont render any of the primitives - If the clump intersects the view frustum, add to
PVS and render normally
14Efficient View-Frustum Culling
- Organize clumps into a hierarchy of bounding
volumes for more efficient testing - Bound every natural group of primitives by a
simple volume (e.g., sphere, box) - If a bounding volume (BV) is outside the view
frustum, then the entire contents of that BV is
also outside (not visible) - Avoid further processing of such BVs and their
containing geometry - Use a scene graph
15Scene graph example
scene graph
circlesBVs
root
16Example of Hierarchical View Frustum Culling
camera
17Efficient View-Frustum Culling
- What shape should bounding volumes be?
- Spheres and axis-aligned bounding boxes simple
to calculate, cheap to test - Oriented bounding boxes converge asymptotically
faster in theory - Lots of other volumes have been proposed
- Capsules, ellipsoids, k-DOPs
- but most use spheres or AABBs.
18Frustum Culling
- Sphere testing
- A sphere is defined by a center point and a
radius - Part of the sphere is still in front of the plane
(and thus, it cant be culled) even if the center
point is up to radius units on the back side of
the plane - Recall that Ax By Cz D is the distance from
the point (x, y, z) to the plane - derive
- Thus, we keep the sphere if the sphere center
plugged into this equation produces values gt
-radius for all 6 plane equations
19Frustum Culling
- Cube test
- A cube consists of 8 vertices
- Usually pass in as a center location and a size
- We could test to see if any of the 8 cube
vertices are within the Frustum (i.e. test each
vertex against all 6 planes) - However, this leads to problems when the cube is
bigger than the Frustum all 8 corners are
outside the Frustum, but the cube contents should
be drawn - False negatives cube culled when it shouldnt be
20Frustum Culling
- Instead we reverse the order and test all 8
points against a single plane - If all are to the back side of the plane then the
cube is not visible and we can cull it - If any are in front, then we move onto the next
plane - If it passes all 6 planes then we keep it
- However, this can lead to false positives (see
figure) - We let it though and simply let the card cull it
on a triangle by triangle basis
21Frustum Culling
- So what sort of speed up do you get?
- It depends on several factors
- How big the Frustum is (especially the far plane)
- How many object are in the scene and how they are
distributed - How complex each particular object is
22Cells Portals
- Goal walk through architectural models
(buildings, cities, catacombs) - These divide naturally into cells
- Rooms, alcoves, corridors
- Transparent portals connect cells
- Doorways, entrances, windows
- Notice cells only see other cells through portals
23Cells Portals
24Cells and Portals
- Luebke (1995) view-dependent only
- Eye-portal visibility determined by intersecting
portal cull boxes - No preprocess (integrate w/ modeling)
- Quick, simple hack
- Public-domain library pfPortals
25Cell and Portal Visibility
- Start in the cell containing the viewer, with the
full viewing frustum - Render the walls of that room and its contents
- Recursively clip the viewing frustum to each
portal out of the cell, and call the algorithm on
the cell beyond the portal
26Cell-Portal Example (1)
View
27Cell-Portal Example (2)
View
28Cell-Portal Example (3)
View
29Cell-Portal Example (4)
View
30Cell-Portal Example (5)
View
31Cell-Portal Example (6)
View
32Detail Culling
- Idea objects whose projected BV occupy less than
N pixels are culled - This is an approximative algorithm as the things
you cull away may actually contribute to the
final image - Advantage trade-off quality/speed
33Example of Detail Culling
Images courtesy of ABB Robotics Products, created
by Ulf Assarsson
detail culling OFF
detail culling ON
- Not much difference, but 80-400 faster
- Good when moving
34Occlusion Culling
- Main idea Objects that lies completely behind
another set of objects can be culled - Hard problem to solve efficiently
35Example
final image
- Note that Portal Culling is an algorithm for
occlusion culling
36Occlusion culling algorithm
- Use some kind of occlusion
- representation OR
- for each object g do
- if( not Occluded(OR ,g))
- render(g)
- update(OR ,g)
- end
- end
37Occlusion culling algorithm example
- Process from front to back
- Maintain an occlusion horizon (yellow)
38Occlusion culling algorithm example
- To process tetrahedron (which is behind grey
objects) - find axis-aligned box of projection
- compare against occlusion horizon
culled
39Occlusion culling algorithm example
- When an object is considered visible
- Add its occluding power to the occlusion
representation
40Simplify Geometry
- One polygon
- Sprites
- Billboards
- Impostors
- Many polygons
- Level of detail (LOD)
41Sprites
- Sprite
- An image that moves around on the screen
- Ex. Mouse cursor
- rectangular shape
- One-to-one mapping with pixels on the screen
- The earliest PC graphics were sprite
- Implementation
- An image texture on a polygon with the use of
alpha channel
background
sprite image
result
42Billboarding
- Billboarding
- Textured polygon
- Combined with alpha texturing and animation
- ex. smoke, fire, explosions, vapor trails, clouds
43Billboarding
- Axial Billboard
- to rotate around some fixed world-space axis and
align itself so as to face the viewer - Useful for representing objects with cylindrical
symmetry - displaying trees
- Problem if the viewer flies over the trees and
looks straight down, the illusion is ruined.
Direct3D Billboarding Tree
44Multi-Polygon Billboards
- Use two polygons at right angles
- No alignment with viewer
- Use more polygons for better appearance
45Impostors
- Replace 3D geometry with a 2D image
- 2D image fools viewer into thinking 3D geometry
is still there - Prior work
- Trompe loeil (trick of the eye) painting style
- Theater/movie backdrops
- Big limitation
- No parallax
Harnett 1886
46Impostors Technique
- Basic idea
- First, render set of geometry into a large
texture an impostor - Now render impostor texture instead of the
geometry - Helps when impostors can be reused across many
frames
47Impostors Example
- We render a set of geometry into an impostor
(image/texture)
48Impostors Example
- We can re-use this impostor in 3D for several
frames
49Impostors Example
- Eventually, we have to update the impostor
50Level of Detail
- Level of detail (LOD) is an important tool for
maintaining interactivity - Focuses on the fidelity / performance tradeoff
51Level of Detail The Basic Idea
- The problem
- Geometric datasets can be too complex to render
at interactive rates - One solution
- Simplify the polygonal geometry of small or
distant objects - Known as Level of Detail or LOD
- A.k.a. polygonal simplification, geometric
simplification, mesh reduction, decimation,
multiresolution modeling,
52Level-of-Detail Rendering
- Use different levels of detail at different
distances from the viewer - More triangles closer to the viewer
53LOD rendering
- Not much visual difference, but a lot faster
- Use area of projection of BV to select
appropriate LOD
54Scene graph with LODs
55Another Example
69,451 polys
2,502 polys
251 polys
76 polys
Courtesy Stanford 3D Scanning Repository
56Another Example
57Level of DetailThe Big Questions
- How to represent and generate simpler versions of
a complex model?
69,451 polys
2,502 polys
251 polys
76 polys
Courtesy Stanford 3D Scanning Repository
58Level of DetailThe Big Questions
- How to evaluate the fidelity of the simplified
models?
69,451 polys
2,502 polys
251 polys
76 polys
Courtesy Stanford 3D Scanning Repository
59Level of DetailThe Big Questions
- When to use which LOD of an object?
69,451 polys
2,502 polys
251 polys
76 polys
Courtesy Stanford 3D Scanning Repository
60Some Background
- History of LOD techniques
- Early history Clark (1976), flight simulators
- Handmade LODs ? automatic LODs
- LOD run-time management reactive ? predictive
(Funkhouser) - LOD frameworks
- Discrete (1976)
- Continuous (1996)
- View-dependent (1997)
61Topology and SA
- Topology-preserving algorithms
- Preserve manifold connectivity at every step
(dont close up or create holes)
Yes Yes No
62Traditional Approach Discrete Level of Detail
- Traditional LOD in a nutshell
- Create LODs for each object separately in a
preprocess - At run-time, pick each objects LOD according to
the objects distance (or similar criterion) - Since LODs are created offline at fixed
resolutions, we call this discrete LOD
63 Level-of-detail (LOD)
Clark76 Funkhouser93
distance from viewer?
close
far
10,000
2,000
1,000
500
250
64Discrete LODAdvantages
- Simplest programming model decouples
simplification and rendering - LOD creation need not address real-time rendering
constraints - Run-time rendering need only pick LODs
65Choosing LODsLOD Run-Time Management
- Fundamental LOD issue where in the scene to
allocate detail? - For discrete LOD this equates to choosing which
LOD will represent each object
66Choosing LODs
- Assign each LOD a range of distances
- Calculate distance from viewer to object
- Use corresponding LOD
67Choosing LODs
- Whats wrong with this simple approach?
- Visual pop when switching LODs can be
disconcerting - Doesnt maintain constant frame rate lots of
objects still means slow frame times - Requires someone to assign switching distances by
hand - Correct switching distance may vary with field of
view, resolution, etc.
68Choosing LODsMaintaining constant frame rate
- One solution scale LOD switching distances by a
bias - Implement a feedback mechanism
- If last frame took too long, decrease bias
- If last frame took too little time, increase bias
- Dangers
- Oscillation caused by overly aggressive feedback
- Sudden change in rendering load can still cause
overly long frame times
69Choosing LODsMaintaining constant frame rate
- A better (but harder) solution predictive LOD
selection - For each LOD estimate
- Cost (rendering time)
- Benefit (importance to the image)
70Choosing LODsMaintaining constant frame rate
- A better (but harder) solution predictive LOD
selection - For each LOD estimate
- Cost (rendering time)
- of polygons
- How large on screen
- Vertex processing load (e.g., lighting) OR
- Fragment processing load (e.g., texturing)
- Benefit (importance to the image)
71Choosing LODsMaintaining constant frame rate
- A better (but harder) solution predictive LOD
selection - For each LOD estimate
- Cost (rendering time)
- Benefit (importance to the image)
- Size larger objects contribute more to image
- Accuracy no of verts/polys, shading model, etc.
- Priority account for inherent importance
- Eccentricity peripheral objects harder to see
- Velocity fast-moving objects harder to see
- Hysteresis avoid flicker use previous frame
state
72Choosing LODsFunkhouser Sequin, SIGGRAPH 93
- Given a fixed time budget, select LODs to
maximize benefit within a cost constraint - Sort objects by benefit/cost ratio, pick in
sorted order until budget is exceeded
73Discrete LODAdvantages
- Fits modern graphics hardware well
- Easy to compile each LOD into triangle strips,
display lists, vertex arrays, - These render much faster than unorganized
triangles on todays hardware (3-5 x)
74Continuous Level of Detail
- A departure from the traditional discrete
approach - Discrete LOD create individual levels of detail
in a preprocess - Continuous LOD create data structure from which
a desired level of detail can be extracted at run
time.
75Traditional mesh representation
mesh M
V
F
Vertex 1 x1 y1 z1 Vertex 2 x2 y2 z2
Face 1 2 3 Face 3 2 4 Face 4 2 7
(appearance attributes normals, colors,
textures, ...)
76New mesh simplification procedure
- Idea apply sequence of edge collapses
ecol(vs ,vt , vs )
vt
vl
vr
vl
vr
vs
vs
S
77Simplification process
13,546
500
152
150
M0
M1
M175
ecol0
ecoli
ecoln-1
78Invertible!
- Vertex split transformation
attributes
vspl(vs ,vl ,vr , vs ,vt ,)
vt
vl
vr
vl
vr
vs
vs
S
79Reconstruction process
S
V
80Continuous LODAdvantages
- Better granularity ? better fidelity
- LOD is specified exactly, not chosen from a few
pre-created options - Thus objects use no more polygons than necessary,
which frees up polygons for other objects - Net result better resource utilization, leading
to better overall fidelity/polygon
81Continuous LODAdvantages
- Better granularity ? smoother transitions
- Switching between traditional LODs can introduce
visual popping effect - Continuous LOD can adjust detail gradually and
incrementally, reducing visual pops - Can even geomorph the fine-grained simplification
operations over several frames to eliminate pops
Hoppe 96, 98
82Continuous LODAdvantages
- Supports progressive transmission
- Progressive Meshes Hoppe 97
- Progressive Forest Split Compression Taubin 98
- PM movie
- Leads to view-dependent LOD
- Use current view parameters to select best
representation for the current view - Single objects may thus span several levels of
detail
83View-Dependent LOD Examples
- Show nearby portions of object at higher
resolution than distant portions
View from eyepoint
Birds-eye view
84View-Dependent LOD Examples
- Show silhouette regions of object at higher
resolution than interior regions
85View-Dependent LODAdvantages
- Even better granularity
- Allocates polygons where they are most needed,
within as well as among objects - Enables even better overall fidelity
- Enables drastic simplification of very large
objects - PM movie
86Summary LOD Frameworks
- Discrete LOD
- Generate a handful of LODs for each object
- Continuous LOD (CLOD)
- Generate data structure for each object from
which a spectrum of detail can be extracted - View-dependent LOD
- Generate data structure from which an LOD
specialized to the current view parameters can be
generated on the fly. - One object may span multiple levels of detail