Transcript BSP Trees

Advanced Data Structures
for Games and Graphics
Lecture 4
Advanced Programming for 3D Applications
Overview
• Spatial Data Structures
•
•
•
•
•
– Why care?
– Octrees/Quadtrees
– Operations on tree-based spatial data structures
Kd-trees
BSP trees
BVHs (Bounding Volume Hierarchies)
Cell Structures (Graph-Based)
Visibility
– Portal based
– Occlusion culling
2
Spatial Data Structures
• Used to organize geometry in n-dimensional space (2
•
•
•
and 3D)
For accelerating queries – culling, ray tracing
intersection tests, collision detection
They are mostly hierarchy (Tree-Based) by nature
Examples:
– Bounding Volume Hierarchies (BVH)
– Binary Space Partitioning Trees (BSP trees)
– Octrees
3
Spatial Data Structures
• Spatial data structures store data indexed in some
way by their spatial location
– For instance, store points according to their location, or polygons,
…
• Multitude of uses in computer games
–
–
–
–
4
Visibility - What can I see?
Ray intersections - What did the player just shoot?
Collision detection - Did the player just hit a wall?
Proximity queries - Where is the nearest power-up?
Spatial Decompositions
• Focus on spatial data structures that partition space
into regions, or cells, of some type
– Generally, cut up space with planes that separate regions
– Almost always based on tree structures
• Octrees (Quadtrees): Axis aligned, regularly spaced
planes cut space into cubes (squares)
• Kd-trees: Axis aligned planes, in alternating
directions, cut space into rectilinear regions
• BSP Trees: Arbitrarily aligned planes cut space into
convex regions
5
Octrees
• Similar to Axis-Aligned BSP trees
• Each node has eight children
• A parent has 8 (2x2x2) children
• Subdivide the space until the
number of primitives within
each leaf node is less than a
threshold
• Objects are stored in the leaf
nodes
6
Octree
• Root node represents a cube containing the entire
•
•
world
Then, recursively, the eight children of each node
represent the eight sub-cubes of the parent
Objects can be assigned to nodes in one of two
common ways:
– All objects are in leaf nodes
– Each object is in the smallest node that fully contains it
– What are the benefits and problems with each approach?
7
Octree Node Data Structure
• What needs to be stored in a node?
– Children pointers (at most eight)
– Parent pointer - useful for moving about the tree
– Extents of cube - can be inferred from tree structure, but
easier to just store it
– Data associated with the contents of the cube
• Contents might be whole objects or individual polygons, or
even something else
– Neighbors are useful in some algorithms
8
Building an Octree
• Define a function, buildNode, that:
– Takes a node with its cube and set a list of its
contents
– Creates the children nodes, divides the objects
among the children, and recurses on the children,
or
– Sets the node to be a leaf node
• Find the root cube, create the root node and
•
9
call buildNode with all the objects
When do we choose to stop creating
children?
Example Construction
10
Frustum Culling With Octrees
• We wish to eliminate objects that do not intersect the
•
view frustum
Have a test that succeeds if a cell may be visible
– Test the corners of the cell against each clip plane. If all the
corners are outside one clip plane, the cell is not visible
– Otherwise, is the cell itself definitely visible?
• Starting with the root node cell, perform the test
– If it fails, nothing inside the cell is visible
– If it succeeds, something inside the cell might be visible
– Recurse for each of the children of a visible cell
• This algorithm with quadtrees is particularly effective
for certain type of game.
11
Visibility Culling
• Back face culling
• View-frustrum culling
• Detail culling
• Occlusion culling
12
View-Frustum Culling
• Done in the application stage
• Remove objects that are outside the
viewing frustum
• Can use BVH, BSP, Octrees
1. Create hierarchy
2. BV/V-F intersection
tests
13
View-Frustum Culling
• Often done hierarchically to save time
In-order, top-down
traversal and test
14
Detail Culling
• A technique that sacrifices quality for
speed
• Base on the size of projected BV – if
it is too small, discard it.
• Also often done
hierarchically
Always helps to create a hierarchical
structure.
15
Occlusion Culling
• Discard objects that are occluded
• Z-buffer is not the smartest algorithm in the
•
•
16
world (particularly for high depthcomplexity scenes)
We want to avoid processing invisible objects
Combine Spatial Data Structure and Z-Buffer
Occlusion Culling (2)
OcclusionCulling (G)
Or = empty
For each object g in G
if (isOccluded(g, Or))
skip g
else
render (g)
update (Or)
end
End
17
G: input graphics data
Or: occlusion hint
Things needed:
1. Algorithms for isOccluded()
2. What is Or?
3. Fast update Or
Kd-trees
• A kd-tree is a tree with the following properties
– Each node represents a rectilinear region (faces aligned with
axes)
– Each node is associated with an axis aligned plane that cuts its
region into two, and it has a child for each sub-region
– The directions of the cutting planes alternate with depth –
height 0 cuts on x, height 1 cuts on y, height 2 cuts on z,
height 3 cuts on x, …
• Kd-trees generalize octrees by allowing splitting planes
at variable positions
– Note that cut planes in different sub-trees at the same level
need not be the same
18
Kd-tree Example
4
6
1
10
8
2
11
3
13
2
3
4
5
6
7
12
8
9
5
19
1
7
9
10
11
12
13
Kd-tree Example
4
6
1
10
8
2
11
3
13
2
3
4
5
6
7
12
8
9
5
20
1
7
9
10
11
12
13
Kd-tree Example
4
6
1
10
8
2
11
3
13
2
3
4
5
6
7
12
8
9
5
21
1
7
9
10
11
12
13
Kd-tree Node Data Structure
• What needs to be stored in a node?
–
–
–
–
–
22
Children pointers (always two)
Parent pointer - useful for moving about the tree
Extents of cell - xmax, xmin, ymax, ymin, zmax, zmin
List of pointers to the contents of the cell
Neighbors are complicated in kd-trees, so typically
not stored
Building a Kd-tree
• Define a function, buildNode, that:
– Takes a node with its cell defined and a list of its contents
– Sets the splitting plane, creates the children nodes, divides
the objects among the children, and recurses on the
children, or
– Sets the node to be a leaf node
• Find the root cell, create the root node and call
•
23
buildNode with all the objects
When do we choose to stop creating children?
Choosing a Splitting Plane
• Two common goals in selecting a splitting plane for
each cell
– Minimize the number of objects cut by the plane
– Balance the tree: Use the plane that equally divides the
objects into two sets (the median cut plane)
– One possible global goal is to minimize the number of
objects cut throughout the entire tree
• One method (assuming splitting on plane
perpendicular to x-axis):
– Sort all the vertices of all the objects to be stored according
to x
– Put plane through median vertex, or locally search for low
cut plane
24
BSP Trees
• Binary Space Partition trees
– A sequence of cuts that divide a region of space into two
• Cutting planes can be of any orientation
– A generalization of kd-trees, and sometimes a kd-tree is
called an axis-aligned BSP tree
• Divides space into convex cells
• The industry standard for spatial subdivision in game
environments
– General enough to handle most common environments
– Easy enough to manage and understand
– Big performance gains
25
Binary Space Partitioning (BSP)
Trees
• Main purpose – depth sorting
• Consisting of a dividing plane, and a BSP tree on
each side of the dividing plane (note the
recursive definition)
• The back to front traversal order can be decided
right away according to where the eye is
P
back to front: A->P->B
BSP A
BSP B
26
back to front: A->P->B
BSP Trees (cont’d)
• Two possible implementations:
Axis-Aligned BSP
27
Polygon-Aligned BSP
Axis-Aligned BSP Trees
• Starting with an AABB
• Recursively subdivide into small boxes
• One possible strategy: cycle through the axes
(also called k-d trees)
0
D
B
1b
2
1a
A
A
0
28
1a
E
C
1b
B
C
2
D
E
Polygon-Aligned BSP Trees
• The original BSP idea
• Choose one divider at a time – any polygon intersect with
•
•
•
the plane has to be split
Done recursively until all polygons are in the BSP trees
The back to front traversal can be done exact
The dividers need to be chosen carefully so that a
balanced BSP tree is created
F
B
A
C
B
C
A
D
E
29
result of split
D
E
F
BSP Example
1
1
2
2
A
3
4
out
5
7
3
6
A
C5B
out
B
6
C
30
8
out
D
out
out
• Notes:
D
4
8
7
– Splitting planes end when they
intersect their parent node’s planes
– Internal node labeled with planes,
leaf nodes with regions
BSP Tree Node Data Structure
• What needs to be stored in a node?
– Children pointers (always two)
– Parent pointer - useful for moving about the tree
– If a leaf node: Extents of cell
• How might we store it?
– If an internal node: The split plane
– List of pointers to the contents of the cell
– Neighbors are useful in many algorithms
• Typically only store neighbors at leaf nodes
• Cells can have many neighboring cells
– Portals are also useful - holes that see into neighbors
31
Building a BSP Tree
• Define a function, buildNode, that:
– Takes a node with its cell defined and a list of its contents
– Sets the splitting plane, creates the children nodes, divides
the objects among the children, and recurses on the
children, or
– Sets the node to be a leaf node
• Create the root node and call buildNode with all the
objects
– Do we need the root node’s cell? What do we set it to?
• When do we choose to stop creating children?
32
Choosing Splitting Planes
• Goals:
– Trees with few cells
– Planes that are mostly opaque (best for visibility
calculations)
– Objects not split across cells
• Some heuristics:
–
–
–
–
–
–
33
Choose planes that are also polygon planes
Choose large polygons first
Choose planes that don’t split many polygons
Try to choose planes that evenly divide the data
Let the user select or otherwise guide the splitting process
Random choice of splitting planes doesn’t do too badly
BSP in Current Games
• Use a BSP tree to partition space as you would with
an octree or kd-tree
– Leaf nodes are cells with lists of objects
– Cells typically roughly correspond to “rooms”, but don’t have
to
• The polygons to use in the partitioning are defined by
the level designer as they build the space
34
Bounding Volume Hierarchies
• So far, we have had subdivisions that break the world
•
•
•
35
into cell
General Bounding Volume Hierarchies (BVHs) start
with a bounding volume for each object
– Many possibilities: Spheres, AABBs, OBBs,…
Parents have a bound that bounds their children’s
bounds
– Typically, parent’s bound is of the same type as
the children’s
– Can use fixed or variable number of children per
node
No notion of cells in this structure
Bounding Volume Hierarchies
• Bounding Volume (BV) – a volume that encloses a set
•
•
of objects
The idea is to use a much similar geometric shape for
quick tests (frustum culling for example)
Easy to compute, as tight as possible
AABB
Sphere
OBB
• AABB, Sphere – easy to compute, but poor fit
36
Bounding Volume Hierarchies
• Each node has a bounding volume that encloses
the geometry in the entire subtree
• The actual geometry is contained in the leaf node
• Three types of methods: bottom-up, insertion,
and top-down
root
leaves
37
BVH Example
38
BVH Construction
• Simplest to build top-down
– Bound everything
– Choose a split plane (or more), divide objects into sets
– Recurse on child sets
• Can also be built incrementally
– Insert one bound at a time, growing as required
– Good for environments where things are created dynamically
• Can also build bottom up
– Bound individual objects, group them into sets, create
parent, recurse
– What’s the hardest part about this?
39
BVH Operations
• Some of the operations we’ve mentionned work with
BVHs
– Frustum culling
– Collision detection
• BVHs are good for moving objects
– Updating the tree is easier than for other methods
– Incremental construction also helps (don’t need to
rebuild the whole tree if something changes)
• But, BVHs lack some convenient properties
– For example, not all space is filled, so algorithms
that “walk” through cells won’t work
40
Hierarchical Visibility
• One example of occlusion culling
techniques
• Object-space octree
– Primitives in an octree node are hidden if
the octree node (cube) is hidden
– A octree cube is hidden if its 6 faces are
hidden polygons
– Hierarchical visibility test:
41
Hierarchical Visibility
From the root of octree:
• View-frustum culling
• Scan conversion each of the 6 faces and perform zbuffering
• If all 6 faces are hidden, discard the entire node and
sub-branches
• Otherwise, render the primitives inside and traverse
the front-to-back children recursively
A conservative algorithm –
42
Hierarchical Visibility
• Scan conversion the octree faces can be
expensive – cover a large number of
pixels (overhead)
• How can we reduce the overhead?
• Goal: quickly conclude that a large
polygon is hidden
• Method: use hierarchical z-buffer !
43
Portal Culling
• Goal: walk through architectural
models (buildings, cities, catacombs)
• These divide naturally into cells
– Rooms, alcoves, corridors…
• Transparent portals connect cells
– Doorways, entrances, windows…
44 • Notice: cells only see other cells through portals
Portals
• Subdivision of the world into
cells and portals
• Any region of space that
•
45
cannot be seen through a
sequence of portals is never
considered for rendering
Culling cells seen through a
portal is done using a
frustum reduced in size by
the portal boundary
Cells & Portals
• An example:
46
Cells & Portals
• Idea:
– Create an adjacency graph of cells
– Starting with cell containing eyepoint,
traverse graph, rendering visible cells
– A cell is only visible if it can be seen
through a sequence of portals
• So cell visibility reduces to testing portal
sequences for a line of sight…
47
Cells & Portals
E
A
D
B
F
C
G
H
A
B
E
C
D
H
48
F
G
Cells & Portals
E
A
D
B
F
C
G
H
A
B
E
C
D
H
49
F
G
Cells & Portals
E
A
D
B
F
C
G
H
A
B
E
C
D
H
50
F
G
Cells & Portals
E
A
D
B
F
C
G
H
A
B
E
C
D
H
51
F
G
Cells & Portals
E
A
D
B
F
C
G
H
A
B
E
C
D
H
52
F
G
Cells & Portals
E
A
D
B
C
?
F
G
H
A
B
E
C
D
?
H
53
F
G
Cells & Portals
E
A
D
B
C
X
F
G
H
A
B
54
E
C
D
X
H
F
G
Cells & Portals
• View-independent solution: find all cells a
particular cell could possibly see:
E
A
D
B
F
C
G
H
C can only see A, D, E, and H
55
Cells & Portals
• View-independent solution: find all cells a
particular cell could possibly see:
E
A
D
B
F
C
H
56
H will never see F
G
Portal Definitions
• A cell is a region of space
• A portal is a transparent region that
connects cells
– Portals are one-way (front faced)
• A portal is represented by a convex
planar polygon
• Information on cells and the portals
connecting them are stored in an
adjacency graph
57
Portal Rendering
1. Initialize the current frustum to the entire view
2.
3.
frustum
Set the active cell to be the cell in which the
camera resides and draw this cell
For each visible portal in the currently active cell
do:
1.
2.
Find the reduced view frustum due to the portal
Recursively draw the cell at the other side of the portal,
using the reduced view frustum
E
A
D
B
58
F
C
H
G
Cell-Portal Structures
• Cell-Portal data structures dispense with the
hierarchy and just store neighbor information
– This make them graphs, not trees
• Cells are described by bounding polygons
• Portals are polygonal openings between cells
• Good for visibility culling algorithms, OK for collision
detection and ray-casting
• Several ways to construct
– By hand, as part of an authoring process
– Automatically, starting with a BSP tree or kd-tree and
extracting cells and portals
– Explicitly, as part of an automated modeling process
59
Cell-Portal Visibility
• Keep track of which cell the viewer is in
• Somehow walk the graph to enumerate all
the visible regions
• Cell-based: Preprocess to identify the
potentially visible set (PVS) for each cell
– Set may contain whole cells or individual
objects
• Point-based: Traverse the graph at runtime
– Granularity can be whole cells, regions,
or objects
• Trend is toward point-based, but cell-based
is still very common
60
Runtime Portal Visibility
• Define a procedure renderCell:
– Takes a view frustum and a cell
• Viewer not necessarily in the cell
– Draws the contents of the cell that are in the
frustum
– For each portal out of the cell, clips the frustum to
that portal and recurses with the new frustum and
the cell beyond the portal
• Make sure not to go to the cell you entered
• Start in the cell containing the viewer, with
•
61
the full viewing frustum
Stop when no more portals intersect the view
frustum
Potentially Visible Sets
• A Potentially Visible Set (PVS) is an array stored for
each cell holding the visibility information of all other
cells from that cell
• If cell A is not listed in cell Bs PVS, it cannot possibly
be visible from inside cell B, and therefore doesn’t
need to be considered for rendered
• Unlike basic portal rendering, the cells used for PVS
calculations must be convex regions
62
Potentially Visible Sets
• PVS: The set of cells/regions/objects/polygons that can be seen
from a particular cell
– Generally, choose to identify objects that can be seen
– Trade-off is memory consumption vs. accurate visibility
• Computed as a pre-process
– Have to have a strategy to manage dynamic objects
• Used in various ways:
– As the only visibility computation - render everything in the
PVS for the viewer’s current cell
– As a first step - identify regions that are of interest for more
accurate run-time algorithms
63
Why not just Frustum Culling?
• A PVS can be pre-
•
64
calculated, thus at
runtime large portions
of the scene can be
culled without any
testing at all
A PVS can rule out cells
that, although inside
the view frustum,
cannot possibly be
visible
Calculating the PVS
• A cell A is potentially visible from cell B through a portal
•
•
65
sequence, if and only if there exists a straight line
stabbing all portals in the sequence
If a cell A is connected to cell B through a single portal
only, it is always part of cell Bs PVS
If a cell A is connected to cell B through a sequence of
two portals, it is part of cell Bs PVS unless the two
portals are coplanar
Cell-to-Cell PVS
• Cell A is in cell B’s PVS if there exist a
stabbing line that originates on a portal of B
and reaches a portal of A
– A stabbing line is a line segment intersecting only
portals
– Neighbor cells are trivially in the PVS
I
J
F
H
B D
C
66
E
A
G
PVS for I contains:
B, C, E, F, H, J
Direct Portal Rendering vs.
PVS
• Setup cost and preprocessing time
– PVS calculation is a time consuming process, and is best done
in a preprocessing step, however once it has been calculated,
using it is practically for free
– Direct portal rendering requires no preprocessing, however
there is a run time cost as passing through a portal requires
regenerating the viewing volume
• Few or many portals
– PVS rendering is (nearly) unaffected by the number of portals
and cells
– Because of the cost for passing a portal and regenerating the
viewing volume, direct portal rendering is best suited for scenes
with a moderate number of portals
• Automatic or manual portal placement
– Currently, the only automatic portal placement algorithms
produce a large number of portals. Automatic portal placement
is therefore currently only suited for PVS based systems
67
Direct Portal Rendering vs.
PVS
• Static or dynamic portals
– As PVS calculations are slow, and moving a portal
requires recalculating the PVS, the portals in a PVS
system must be static
– Direct portal rendering requires no precalculations, so a portal is free to move without
introducing a performance penalty
• Underlying data structure
– PVS rendering is well suited for leaf BSP trees, as
the leafs are convex regions of space connected
through portals
– Direct portal rendering is not suitable for
combination with leaf BSP trees due to the high
number of portals generated this way
68
3D Collision detection
• When entities are an irregular shape, a number
of spheres may be used.
• In this diagram we use three spheres for
greater accuracy.
• Geometry in games may be better suited to
bounding boxes (not circles).
69
• To ease calculations, bounding boxes are
commonly axis aligned (irrelevant of entity
transformations they are still aligned to X, Y
and Z coordinates in 3D) These are commonly
called AABBs (Axis Aligned Bounding
Boxes).
Recursive testing of bounding
boxes
• We can build up a recursive hierarchy of bounding boxes to
determine quite accurate collision detection.
70
• Here we use a sphere to test for course grain intersection.
• If we detect intersection of the sphere, we test the two sub
bounding boxes.
• The lower bounding box is further reduced to two more
bounding boxes to detect collision of the cylinders.
Tree structure used to model
collision detection
B
A
A
D
B
C
•
•
•
•
71
C
D
E
E
A recursive algorithm can be used to parse the tree
structure for detecting collisions.
If a collision is detected and leaf nodes are not null then
traverse the leaf nodes.
If a collision is detected and the leaf nodes are null then
collision has occurred at the current node in the the
structure.
If no collision is detected at all nodes where leaf nodes
are null then no collision has occurred (in our diagram B,
C or D must record collision).
Separating axis
• In 2D we can easily see if two AABBs overlap.
• A pair of AABBs overlap only if
their extents overlap in each axis.
• In our diagram we can see that
overlap only occurs on Y axis, but
not on X.
• To achieve the same for AABBs in a 3D environment we
simply introduce another extent.
72
Implementing sort and sweep
method
• The tests for overlapping can be reduced to simple list manipulation
techniques.
• For each axis:
– Add the axis coordinates of the appropriate plane of each AABB in an
ordered list (A) (you can start at either end of the plane). The result is
an ordered list containing all AABBs under test.
– Parse list A, when you come across a start point add this to list B.
When you come across an end point remove the corresponding start
point from list B.
– If when adding a start point to B and B = , no overlap is recorded.
However, if B   then all the AABBs that currently have start points in
B may be considered overlapping with the object that is currently been
added. Record all these pairs of overlaps in list C.
• If there occurs 2 repetitions in C of any particular pair then these
may be considered collided (this applies for 2D, you need three
repetitions for 3D).
73
3D Worked example
1) Step by step for Xaxis –
Add Sa2 = {Sa2} (no overlap)
c
Yaxis
6
b
5
4
4
Zaxis
a
5
3
2
5
Xaxis
2
4
3
6
4
5
2
2
1
5
Xaxis – {Sa2, Sc3, Sb4, Ea5, Ec5, Eb6}
Yaxis – {Sa2, Sb3, Ea4, Sc4, Eb5, Ec6}
Zaxis – {Sa1, Ea2, Sc2, Sb4, Eb5, Ec5}
•
•
•
•
S or E = start or end;
a, b or c = bounding box identifier;
 = axis coordinate
For example - Sa2.
74
Add Sc3 = {Sa2, Sc3} (overlap) C = {(a,c)}
Add Sb4 = {Sa2, Sc3, Sb4} (overlap) C = {(a,c), (a,b), (b,c)}
2) Step by step for Yaxis –
Add Sa2 = {Sa2} (no overlap)
Add Sb3 = {Sa2, Sb3} (overlap) C = {(a,c), (a,b), (b,c), (a,b)}
Add Ea4 = {Sb3} (remove Sa2)
Add Sc4 = {Sb3, Sc4} (overlap) C = {(a,c), (a,b), (b,c), (a,b),
(b,c)}
3) Step by step for Zaxis –
Add Sa1 = {Sa1} (no overlap)
Add Ea2 = {} (remove Sa1)
Add Sc2 = {Sc2} (no overlap)
Add Sb4 = {Sc2, Sb4} (overlap) C = {(a,c), (a,b), (b,c),
(a,b), (b,c), (b,c)} => Collision