Advanced Data Structures for Games and Graphics Lecture 4 Advanced Programming for 3D Applications

Overview Spatial Data Structures Kd-trees BSP trees 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

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

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 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

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

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?

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

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 call buildNode with all the objects When do we choose to stop creating children?

Example Construction

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.

Visibility Culling Back face culling View-frustrum culling Detail culling Occlusion culling

View-Frustum Culling Done in the application stage Remove objects that are outside the viewing frustum Can use BVH, BSP, Octrees 1. Create hierarchy BV/V-F intersection tests

View-Frustum Culling Often done hierarchically to save time In-order, top-down traversal and test

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.

Occlusion Culling Discard objects that are occluded Z-buffer is not the smartest algorithm in the world (particularly for high depth- complexity scenes) We want to avoid processing invisible objects Combine Spatial Data Structure and Z-Buffer

Occlusion Culling (2) G: input graphics data OcclusionCulling (G) Or = empty For each object g in G if (isOccluded(g, Or)) skip g else render (g) update (Or) end End G: input graphics data Or: occlusion hint Things needed: Algorithms for isOccluded() What is Or? 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

Kd-tree Example 4 6 1 10 8 2 3 11 3 13 2 4 5 6 7 12 8 9 10 11 12 13 9 5 1 7

Kd-tree Example 4 6 1 10 8 2 3 11 3 13 2 4 5 6 7 12 8 9 10 11 12 13 9 5 1 7

Kd-tree Example 4 6 1 10 8 2 3 11 3 13 2 4 5 6 7 12 8 9 10 11 12 13 9 5 1 7

Kd-tree Node Data Structure What needs to be stored in a node? 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 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

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

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 back to front: A->P->B P BSP A BSP B back to front: A->P->B

BSP Trees (cont’d) Two possible implementations: Axis-Aligned BSP 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) 1a 1b A B C 2 D E D E B 2 1b 1a A C

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 A B D E C F B C A D E result of split

BSP Example 1 1 2 2 4 A 3 out 5 7 3 A out B 6 8 out 6 5 C B C out D out Notes: Splitting planes end when they intersect their parent node’s planes Internal node labeled with planes, leaf nodes with regions D 4 8 7

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

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?

Choosing Splitting Planes Goals: Trees with few cells Planes that are mostly opaque (best for visibility calculations) Objects not split across cells Some heuristics: 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

Bounding Volume Hierarchies So far, we have had subdivisions that break the world 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 – easy to compute, but poor fit AABB Sphere OBB

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

BVH Example

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?

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

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:

Hierarchical Visibility From the root of octree: View-frustum culling Scan conversion each of the 6 faces and perform z-buffering 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 –

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 !

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… Notice: cells only see other cells through portals

Portals Subdivision of the world into cells and portals Any region of space that 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:

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…

Cells & Portals A D E F B C G H A E B C D F G H

Cells & Portals A D E F B C G H A E B C D F G H

Cells & Portals A D E F B C G H A E B C D F G H

Cells & Portals A D E F B C G H A E B C D F G H

Cells & Portals A D E F B C G H A E B C D F G H

Cells & Portals A D E ? F B C G H A E B C D F G ? H

Cells & Portals A D E X F B C G H A E B C D F G X H

Cells & Portals View-independent solution: find all cells a particular cell could possibly see: C can only see A, D, E, and H A D H F C B E G A D E H

Cells & Portals View-independent solution: find all cells a particular cell could possibly see: H will never see F A D H F C B E G A D E B C 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

Portal Rendering Initialize the current frustum to the entire view 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: 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 A D E F B C G H

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

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

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 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

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

Why not just Frustum Culling? A PVS can be pre-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 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 PVS for I contains: B, C, E, F, H, J H D B E C G A

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

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 pre-calculations, 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

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). 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. 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 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.

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).

3D Worked example 1) Step by step for Xaxis – c 6 Yaxis b 5 Zaxis a 4 Add Sa2 = {Sa2} (no overlap) Add Sc3 = {Sa2, Sc3} (overlap) C = {(a,c)} Add Sb4 = {Sa2, Sc3, Sb4} (overlap) C = {(a,c), (a,b), (b,c)} c 6 Yaxis b 5 Zaxis a 4 4 5 3 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)} 4 5 2 2 5 2 1 2 4 6 Xaxis 5 3 Xaxis – {Sa2, Sc3, Sb4, Ea5, Ec5, Eb6} Yaxis – {Sa2, Sb3, Ea4, Sc4, Eb5, Ec6} Zaxis – {Sa1, Ea2, Sc2, Sb4, Eb5, Ec5} 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 S or E = start or end; a, b or c = bounding box identifier;  = axis coordinate For example - Sa2.