Space Partitioning

Computer Graphics

What is Space Partitioning?

• A division of 3D space into distinct regions

• Specifically, a tree data structure is used to divide up the world in a hierarchical manner– The tree leaf nodes usually contain pieces

(triangles) of the world– Each leaf holds onto the polygons that are in its

sub-piece of the world

Why Perform Space Partitioning?• Speed

– For example, an accurate model of a Boeing-777 contains over 500M triangles

• You do not want to send 500M tri down the rendering pipeline

– We have seen various mapping techniques to make the model look good with less triangles

– But we can also cut down on the number of triangles by only sending triangles down the pipeline that are in the field of view of the camera

• By dividing the world into pieces we can cull/clip on large scale rather than per triangle as the rendering pipeline does

Types of Space Partitioning

• The two main types we will explore are:– Octrees

– Binary Space Partition (BSP) trees

• However, in the process we will also cover:– Frustum culling

– Bounding Volumes (BVs)

– Potentially Visible Sets (PVS)

– Scene Graphs

Frustum Culling

• In the classic rendering pipeline front-facing triangles are clipped against the Frustum– All 3 vertices outside the volume implies the

triangle is culled (not sent down the pipeline)

• The problem with this technique is that it is triangle-based and doesn’t take into account spatial coherence– All the triangles for a given object lie in about

the same position in space

Frustum Culling

• Why is spatial coherence important?– If an object is out of the Frustum then so are all

its triangles– If we could perform the Frustum check per

object then we could cull all the object’s triangles at the same time with a single test

• Note that this is a software test, but only 1 is made rather than 10s/100s/1000s of hardware tests

Frustum Culling

• How do we perform the test in software?

• First we need to find the planes of the Frustum– Recall that there are 6 planes (near, far, left,

right, top, bottom)

Frustum Culling

• If we can find the plane equation for each then we can test to see which side of the plane a point lies– Recall the plane eqn is: Ax + By + Cz + D = 0

• Where (A, B, C) is the normal of the plane

– If we have a point (x, y, z) and we plug it into this equation, we get:

• Positive on the normal side of the plane (in front)• Zero on the plane• Negative on the non-normal side of the plane (behind)

– A point must be in front of all planes for it to be in the Frustum

Frustum Culling

• So, how do you find the Frustum planes?– After setting up the Camera, get the modelview matrix

and the projection matrix• glGetFloatv( GL_MODELVIEW_MATRIX, mod ); • glGetFloatv( GL_PROJECTION_MATRIX, proj );• Note that you need both because the modelview

sets up the camera position and orientation whereas the projection sets up the shape of the Frustum

– Then multiply the two matrices together• clip = (mod) x (proj)

Frustum Culling

• The A, B, C, and D values can then be extracted from the “clip” matrix– As an example the right plane is:

• A = clip[ 3] - clip[ 0]B = clip[ 7] - clip[ 4]C = clip[11] - clip[ 8]D = clip[15] - clip[12]

• These plane values are then normalized so +/- distances from the plane are correct– Each component (A-D) is divided by sqrt(A2 + B2

+ C2)

Frustum Culling

• This sounds like a lot of work– Not coding, but execution time “work”

• But keep a couple of things in mind:– The Frustum plane equations only need to be

recalculated whenever the camera moves– We are going to test an entire object rather than

a single point• In particular, we will test sphere and cube objects

Frustum Culling

• Why just spheres and cubes?– They make nice Bounding Volumes (BVs)

• A Bounding Volume is a simplified shape that encloses an entire complex object– If the Frustum test against the BV fails then the entire

complex object in the BV is not in the Frustum

• The advantage is that tests against simple shapes are computational much easier to perform than tests against complex shapes

Frustum 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 can’t 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

– Thus, we keep the sphere if the sphere center plugged into this equation produces values > -radius for all 6 plane equations

• The point test is the same, but with > 0

Frustum 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 shouldn’t be

Frustum 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

Frustum 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

– Check out gametutorials Frustum culling tutorial

Octrees

• Octrees are a space partitioning data structure– We saw Octrees before in the context of modeling

• In modeling the leaf nodes were either filled or empty• In space partitioning the leaf nodes contain a list of triangles that are

in that sub-section of space

• The process:– A single cube is placed around the entire world– If the cube contains too many triangles, then the cube is sub-

divided into 8 smaller axis-aligned cubes– Recurse until we hit the stopping condition

Octrees

Octrees

• When do you stop sub-dividing?– When the cube contains less than a specified

number of triangles– When the sub-division depth has reached a

maximum– When the total number of cubes in my octree

has reached a maximum number

Octrees

• What happens to triangles that cross a cube boundary?– Place the object in the largest box that fully contains it

• Not efficient in that a small object can be placed in a large bounding box if it lies directly on the boundary

• Implies that not all triangles are stored in the leaf nodes

– Split the triangle• Increases the number of primitives in the scene

– Place the triangle in both sub-divisions• As the triangles from each sub-division are sent to the renderer

we need to mark them so we don’t draw them twice• Makes Octree editing, such as deletion, is more difficult

Octrees

• So how to Octrees help us?– We can combine Octrees with Frustum culling

• The Octree cubes are Bounding Volumes for the triangles in their region of space

• We only need to send the triangles contained in the cubes that pass the Frustum test to the rendering pipeline

Octrees

• This leads to a process called Hierarchical Frustum Culling– Starting with the root node of the Octree, test

the Octree cube against the Frustum• If not in frustum, then prune children• If in frustum, then

– Send any contained triangles to renderer– Recurse on each of the children

– Demo Octree2 and Octree3 from gametutorials

BSP Trees

• The idea is much the same as with Octrees• However, the space is repeatedly split into 2

parts (hence the name “binary space partition”) by a given splitting plane– Octrees always use cubes

• There are two variants– Axis-Aligned– Polygon Aligned

Axis-Aligned BSP Trees

• Starting with a bounding box around the entire world, split it into 2 parts with an xy, xz, or yz splitting plane

• Divide all the triangles between the two half-spaces• Triangles that intersect the splitting plane can be dealt with

the same way we did with Octrees• Recursively continue the

subdivision process until astopping criteria is reached– Note that each successive

subdivision only splits its ownhalf-space

Axis-Aligned BSP Trees

• The interesting part is how to decide what axis and where along that axis to split

• Suggestions on how?– Hint: how does all this relate to what you

learned in cs255 about merge sort vs. quick sort

Polygon-Aligned BSP Trees

• In this version, a polygon is chosen as the divider polygon

• This polygon is part of a plane and it is this plane that is used as the splitting plane

Polygon-Aligned BSP Trees

• Just as with Axis-Aligned BSP trees the most important choice is the selection of the polygon divider

• There are two main issues to consider:– How balanced is the tree– How many extra triangles did we have to make because of triangle

splitting

• It is a debatable question as to which is better:– A balanced tree with lots of extra triangles– A unbalanced tree with fewer extra triangles

• However most people pick the unbalanced tree with fewer splits of triangles

Polygon-Aligned BSP Trees

• Generating an optimal BSP tree requires trying every possible splitting combination– The problem is that this is a O(n!) algorithm

• Recall that 20! = 2,432,902,008,176,640,000

• The next best option is to pick the best splitter at each level– Divide-and-Conquer with a Greedy selection of the

splitter at each level– This is an O(n2) algorithm– This is the option that most games use

• However, it is still pre-computed and saved in a file

BSP Trees

• Hierarchical Frustum Culling can be used fairly easily with Axis-Aligned BSP trees– Very similar to how it was used for Octrees since each

region is rectangular

• However, for Polygon-Aligned BSP trees testing is more complex– The region (leaf or interior) in question is convex, so one

could test all the corners of the region the same way the 8 corners are tested for rectangular regions

– Or a bounding box of the region can be tested• Quicker test, but more false positives (passed frustum test when not

actually in the fustum

BSP Trees

• However, Polygon-Aligned BSP trees have their advantage in visibility– Allow us to easily perform a visibility ordering– Allow us to align splitting planes along walls

which may not be axis aligned

BSP Tree Visibility

• In complex indoor scenes, not only do we have lots of geometry that is not in the camera’s frustum but we also have lots of geometry that is hidden by walls– That is, the frustum might extend through many walls

• Frustum culling would simply select all nodes it intersected and send them to the renderer where a Z-buffer technique is used to handle the occlusion in the normal way

• With Polygon-Aligned BSP Trees we can determine visibility ordering w.r.t. a given camera position– Works in linear time– Works for any given camera position

BSP Tree Visibility

• In order to determine the visibility ordering– First, build the BSP tree for the scene

• Usually done off-line

• For a static scene– Dynamic scenes objects are usually handled separately

– Second, insert a viewpoint into the scene

– Third, perform a in-order traversal of the tree to determine the polygon order

• Recall in-order traversals mean process child, process node, process other child

BSP Tree Visibility

• What order should we process the children in?

• To obtain a back-to-front ordering– Process the far-side child first

• Relative to the location of the camera

• To obtain a front-to-back ordering– Process the near-side child first

BSP Tree Visibility

• Back-to-front: C1, B, D, A, C2, E

• Front-to-back: E, C2, A, D, B, C1

BSP Tree Visibility

• Back-to-front ordering leads to a version of the “painters algorithm”

• This doesn’t suffer from the intersecting problem seen previously in the painters algorithm– Any polygons that would have intersected have now been

split into multiple pieces

• However, the painters algorithm is still really slow– Pixels will be drawn only to be overdrawn by closer tris

• Often 10x overdraws (Michael Abrash of Quake frame)

– Overdraw amount varies so framerate is not stable– Overdraw problems increase with scene complexity

BSP Tree Visibility

• Front-to-back has no overdraw problems– Each pixel is drawn exactly once

• But we need to find a way to not overwrite a pixel once it has been drawn– Could use the normal Z-buffer technique

• However, this is overkill since we will never need to replace a value in the Z-buffer with a newer one

– Could use a Stencil buffer technique• Stencil filters pixels that have already been drawn• As new pixels are drawn, the stencil buffer is updated

• This technique is usually faster than back-to-front

Stencil Buffer

• A Stencil Buffer is another buffer like the color (frame) buffer and the Z-buffer– On most hardware this is an 8 bit buffer

• The Stencil Test is a test that occurs immediately before the Z-buffer test– If the Stencil Test fails, the fragment is

discarded rather than passed on to the Z-buffer• Fragment won’t show up in the color buffer either

Stencil Buffer

• The Stencil Test is a test of the value currently stored in the Stencil Buffer

• The Stencil Function controls the type of Stencil Test to perform:

GL_NEVER GL_ALWAYS

GL_LESS GL_LEQUAL

GL_EQUAL GL_NOTEQUAL

GL_GREATER GL_GEQUAL

Stencil Buffer

• There are 3 possible outcomes of the combined Stencil and Z-buffer tests:– Stencil Test fails– Stencil Test passes, Depth Test fails– Stencil Test passes, Depth Test passes

• The Stencil Operation lets you specify what happens to the Stencil Buffer values in each of these cases

Stencil Buffer

• The possible Stencil Operations are:– GL_KEEP old value kept

– GL_ZERO value replaced by zero

– GL_REPLACE value replaced by given reference value (allows setting to a specific value)

– GL_INCR value incremented by 1

– GL_DECR value decremented by 1

– GL_INVERT value bitwise inverted

Stencil Buffer

• The Stencil buffer/test are only performed if– The Stencil buffer is enabled– The underlying hardware/drivers support it

• The stencil buffer is usually used as a mask– Example: creating a non-rectangular windshield

for a first-person driving game• Store 1s in the stencil buffer pixels where you wish

the windshield to be and then set the stencil test to render if not equal to 0

BSP Tree Visibility

• Note that the visibility ordering is not directly related to either:– Viewing direction

• Both A and B appear in the visibility ordering even though camera is facing the other direction

– Distance of the polygons from the viewpoint• In back-to-front ordering, B is before A in both figures even

though A is sometimes farther than B from the camera

BSP Tree Visibility

• The previous slides have assumed that the BSP tree will continue dividing until every polygon is used as a splitting plane

• However, in indoor scenes we often want to use BSP trees aligned with the walls to provide visibility on a room level and then let the normal Z-buffer algorithm handle objects within the room– That is, a hybrid visibility scheme

Portals

• World is divided up into Cells and Portals

• Cells are convex regions– Could be BSP tree leaves

• Portals are doorways/windows between the Cells

Portals

• Basic algorithm:– Start in the cell that contains the camera

• Equating Cells to BSP tree leaves helps here

– Perform a frustum check against all objects in the current cell to determine what is visible

– If any portals are visible (in frustum), add the connecting cell to the list of cells to process

– Continue until all visible cells have been rendered

Portals

• An optimization of the previous algorithm is frustum reduction

• When a portal is visible, it means the cell it leads to is visible, but only partially, because the camera can only see this cell through the portal

• Thus, the frustum can be reduced in the new cell– Cuts down the number of objects in the cell that are sent

to the renderer

– And cuts down on the number of “visible” portals seen which reduces the amount of recursion

Portals

– The reduced frustum is created by planes from the camera through the portal edges

• For portals with vertical walls, it turns into a 2D issue of casting rays through points

PVS

• Techniques that were tried and rejected for large-scale culling in Quake

• Pure Z-buffering

• Painters algorithm

• Beam tree

• Subdividing raycasting

• Edge or Span sorting

• Portals

• Direct visibility extraction from BSP

• Instead Quake went with PVS

PVS

• Potentially Visible Sets (PVS) involve pre-computing visibility information from the BSP tree– That is, first divide up the world using a BSP tree, storing

all the polygon faces in the leaf nodes– Next, perform off-line visibility checks to determine

which leaf nodes are visible from which other leaf nodes creating a 2D visibility matrix

• Visible from anywhere in the source leaf node

– The 2D visibility matrix information, called a Potentially Visible Set (PVS) is then used to cull large parts of the BSP tree away when rendering

PVS

• The PVS is used by first descending the BSP tree with the camera coordinates to determine in which leaf node the camera resides

• Then the PVS is consulted to determine other leaf nodes that may also need to be rendered

• This can then be combined with frustum culling to test the bounding boxes of these leaf nodes with the frustum

• And finally, the polygons from the surviving leaf nodes are sent to the renderer

PVS

• Creating the PVS is a difficult task– Very time-consuming– Various way to create it, but often portals are

used to create view-independent visibility maps• Note that the previously discussed portal

information was view-dependent (known camera position/orientation)

• If we are going to pre-compute visibility, we need view-independent information

PVS

• The entire cell of the potential camera (blue) is used as the starting cell

• Lines (of sight) are constructed between portal edges to determine which cells are visible– There are more examples

on p.298-301 of Gamesbook

PVS

• The PVS can be built from these portal constructed visibility maps by using every leaf node as a potential starting position and recording all the other leaf nodes that are visible from the starting leaf

Collision Detection

• When objects are moving we need to determine if, when, and where they collide

• Each question gets harder so solve (both computationally and theoretically)– To answer when one also needs to know if – To answer where one also needs to know when

• There are methods that solve all at once, but you can’t solve each successive one without the prior

Collision Detection

• The brute force solution is to test every triangle of each object against every triangle of every other object

• The problem: O(n2 m2)• n is the number of objects

• m is the number of triangles per object

– So it becomes infeasible as scene complexity or object complexity increases

Collision Detection

• The solution is two-fold:– Space Partitioning

• Reduces the n2 term

– Bounding Volumes• Reduces the m2 term

Collision Detection

• We have already seen several Space Partitioning schemes– Octrees– BSP Trees

• An object can only collide with another object that is in the same part of space– This is sometimes called a “collision group”

Collision Detection

• The problem with using space partitioning schemes is that one needs to keep the partitions updated as objects move through space– It certainly can be done, it just takes time

• Loose Octrees hold an advantage here because of their fast insert/delete times

• Often, spatial coherence can be used to quickly determine the object’s new node

• For collision detection of a moving object with only static objects (architectural) the problem is easier since one can avoid updating the tree– Keep only the static objects in the tree and dynamically determine the

moving object’s node

Collision Detection

• Bounding volumes simplify objects– An object containing 10K triangles can be represented

with a single sphere

– Makes collision tests much simpler

• However, false positives can occur– The bounding volumes collide but the objects they

contain do not

• The standard solution is to use a two-phase collision detection scheme

Collision Detection

• The two-phase scheme:– Broad phase:

• Bounding volumes are used to cull away pairs of moving objects that cannot possibly collide

• Leaves some false positives

– Narrow phase:• An exact collision detection method on the pairs that survive

the culling process

• The particular choice of algorithms for each phase can be made independently

Collision Detection• Common Bounding Volumes:

– Sphere– Axis-Aligned Bounding Box (AABB)– Oriented Bounding Box (OBB)– Discrete Orientation Polytope (k-dop)

• Pairs of parallel planes

Collision Detection

• In deciding which is best, there is a tradeoff between bounding efficiency and intersection test speed

• Bounding efficiency is how closely the volume bounds the actual object– Higher bounding efficiency reduces false positives

• Intersection test speed is controlled by the complexity of the shape– Sphere/Sphere intersection is much faster than

kDOP/kDOP intersection

Collision Detection

• One also needs to worry about how to update these volumes for moving objects– Obviously there is the issue of translation

which is easily handled by translating the BV– However, the problems can occur when the

objects can rotate• This is a major problem for AABBs which can’t be

rotated and need to be recalculated• But not a issue at all for Spheres

Collision Detection

• Hierarchies of bounding volumes can be used instead of a single BV

• Collision detection starts at the top of the hierarchy and proceeds downward to the leaf nodes

• The goal is to reduce the number of triangles involved in the narrow phase

Collision Detection

• There are also many other BVs in use– Capsules, Lozenges, Cylinders, Ellipsoids, etc.

• It is somewhat surprising that some simple shapes such as cylinders should be avoided– “intersection testing against a moving cylinder

is extremely complicated and somewhat expensive process”

Collision Detection

• When implementing collision detection, one needs to know the potential shapes involved

• There are sets of (sometimes complex) math equations for intersecting almost any shape against another– Eberly’s 3D Game Engine Design is full of them

• You probably want to keep the shapes in your system to a minimum so you don’t end up with an explosion of testing code

Collision Detection

• Some rules of thumb when implementing intersection routines (from real-time rendering):– Perform computations that might trivially reject or

accept various types of intersections early– Exploit results from previous tests– Postpone expensive calculations (esp. trig functions)

until they are truly needed– If a single object is being tested against many other

objects look for precalculations that can be done once– Watch out for floating-point precision problems

Collision Detection

• There are also difficulties associated with temporal sampling:– If the velocity of an objects is high with respect

to the sampling rate for collision detection then the objects can pass through each other without being detected

– In general, collision will not be detected until after the objects has penetrated each other

Collision Detection

• To help address the problem of objects passing through each other undetected one can use adaptive sampling rates– As objects get closer to each other sample more

frequently

– How do we determine if objects are getting closer?• Most intersection tests can be made to return more than a

Boolean, such as a distance

• Use a larger bounding volume to trigger the need to sample more often

Collision Detection• What do we do when detection occurs?

– This is often called the “collision response”– Recall that most detection occurs after penetration

• Some systems simply need to back the objects away from each other in the direction opposite their direction of travel– Used to prevent objects from going through walls, etc.– This happens before the scene is rendered so the collision is never seen

by the user:• Scene rendered• Objects moved• Collision detection occurs• Collision response activated• Scene rendered• …

Collision Detection

• Other systems that perform more realistic dynamic simulations need to bounce the objects off of each other in a realistic way

• They need to know the exact time of collision• To achieve this we need to back time up to the point of

impact– Most algorithms produce an estimate of the impact time, set the

objects to that time, recalculate the collision test, and recurse if estimate was not accurate enough

• The main problem with this is time cost, specifically non-uniform time cost