Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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