Binary Space Partitions

1

• Binary Space PartitionsCells and Portals
• by Jeff DeBrine

2
Why do we care?

• We want to accelerate rendering!
• These methods are referred to as visibility
  precomputations
• They can reduce the effort involved in solving
  the hidden surface problem during rendering

3
Binary Space Partition (BSP)

• Efficient method for determining object
  visibility by painting surfaces onto the screen
  from back to front
• Good when view point changes but objects in a
  scene are fixed

4

• You subdivide space into two subspaces
• Those in front of the dividing plane
• Those in back of the dividing plane
• This division is done recursively until you are
  finished (no non-null sets remain)
• Sounds mighty vague!
• In fact, the optimal time to stop recursing is
  still being researched

5

• Any polygon intersected by a partitioning plane
  is split in half
• Can balloon BSP tree - O(n3)
• Partitioning was designed for 3-D but easier to
  discuss in 2-D
• Possible to have more than one tree describe the
  same scene

6
The punch-line

• You know that objects in the space behind the
  dividing plane can NEVER obscure objects in the
  front space
• This provides the basis for the rendering
  algorithm
• You always know which objects are farther from
  your viewpoint, so you draw them first

7
Bunny Farm

• Lets consider a bunny farm I borrowed from David
  Luebke
• We want to use a BSP tree to be able to draw the
  bunnies correctly from any view
• In our tree, left branches will be front and
  right branches will be back
• Lets begin

8
Bunny Rendering
9
BSP Trees
Front
Front
Back
Back
10
BSP Trees
Front
Front
Front
Back
Back
Back
11
BSP Trees
Front
Back
12
BSP Trees
13
Done with the tree

• Notice how we are reduced to nodes with just one
  bunny
• We did not have to split any bunnies in this
  example
• In a real BSP tree, you generally have to split
  some polygons
• This will be explained in the next example

14
Rendering the Bunnies

• Now we want to render the bunnies since they are
  nicely divided in the BSP tree
• Set an eye position
• Render from back to front
• Remember the painters algorithm? That is the
  point of the BSP tree.
• We draw from back to front so that objects in
  front obscure the objects in back

15
Rendering
2
1
4
3
5
7
8
6
9
9
1
4
5
6
2
3
7
8
16
Which side am I on?

• With the eye on the right (or back) side, we draw
  the bunnies in the following order
• 1, 2, 3, 4, 5, 6, 7, 8, 9
• Remember to go down the opposite side of the tree
  first
• The next slide shows the eye on the left, so the
  order is reversed
• This ensures that the bunnies in the front are
  drawn last

17
Rendering
2
1
4
3
5
7
8
6
9
9
1
4
5
6
2
3
7
8
18
Next example - DOOM

• When DOOM came out, this was the way it handled
  polygons in a BSP tree
• This example is simplified, but shows some major
  points
• BSP trees can simplify graphics
• Splitting polygons makes BSP trees less efficient
• Works very quickly in certain cases

19
Example
20
Generate a BSP tree

• Lets generate the BSP tree for the previous room
  in DOOM
• First some definitions
• Line is an ordered pair of vertices
• a (A,B) e (E,C) f (C,D) g (F,D)
• Face is the side of the line visible to the
  player
• Some have two faces, some only one

21
More definitions

• A point is to the left of a line if it is to the
  left of the vector between its two vertices,
  taken in order
• Nothing is to the left of line a
• Any questions?

22
Generate

• Lets start with an arbitrary first line, in this
  case f
• Pick a line that doesnt split many others
• Everything to the left of f goes in the left
  subtree. Same for the right subtree

• f
• / \
• / \
• / \
• a,d1,b1 e

23

• The reason lines d and b had to be split was due
  to obscuring by line f
• Neither line d or line b is completely to the
  right or the left of face f
• Left hand side is finished because the walls form
  a convex shape no overlap from any point of view

24

• Now we see that c1 and d2 never overlap so that
  is a terminal node
• Next divide along line g

• f
• / \
• / \
• / \
• a,d1,b1 e
• / \
• / \
• / \
• d2,c1 b2,c2,g

25

• f
• / \
• / \
• / \
• a,d1,b1 e
• / \
• / \
• / \
• d2,c1 g

• g
• / \
• / \
• / \
• c2 c3,b2

26
Done with generation

• Now that we are done creating the tree, lets try
  to render the scene from viewpoint x looking
  north
• We start at the top of the tree and determine
  where we are in relation to line f

27
Example
28

• We see that we are on the right of line f, so we
  start traversing the left side of the tree
• Why the right side of the line?
• Remember the ordering of the vertices
• Why traverse the left side of the tree?
• We want the furthest polygons first

29

• We come to the left-hand-most terminating node
  and write down the faces
• a, d1, b1
• Since were at a dead end, we go back up a level
• Thats f, so we need to determine which face f
  or f
• Note If we were facing south we could not see
  face f so we would not bother going further down
  the tree

30

• Our list now says
• a, d1, b1, f
• We are on the right of line e, so we traverse the
  left side first
• We come to a terminal node and write down
• a, d1, b1, f, d2, c1

31

• Now add the proper face of e
• a, d1, b1, f, d2, c1, e
• Down the right subtree to node g. Were on the
  left so go right and get
• a, d1, b1, f, d2, c1, e, c3, b2

32

• Now add the proper face of g
• a, d1, b1, f, d2, c1, e, c3, b2, g
• Finally, write down the last node
• a, d1, b1, f, d2, c1, e, c3, b2, g, c2
• And were done piece of cake!

33
Problems with BSP trees

• Every polygon must lie in a splitting plane
• You dont want to split more polygons than
  absolutely necessary
• Can generate many new polygons
• All polygons in the scene are explicitly
  processed for each frame

34
Solutions

• Ways to improve
• You can define a bounding box for each subtree
  that encompasses all lines in the subtree
• That way you can skip entire subtrees if the cone
  of vision doesnt intersect the box
• Can check for polygon conflicts (planes that
  intersect other polygons)

35
Quake

• With a 10000 polygon Quake level, a worst-case
  overdraw of ten times or more was not rare
• The Quake BSP does not store polygons in tree
  nodes, but in the leaves
• Each leaf of the BSP has a list of potentially
  visible leaves (the PVS)

36
Quake

• Nodes are splitting planes, with polygons stored
  on them, that carve up space
• Leaves are the convex volumes that nodes carve
  the world into

37
Quake

• If a node's bounding box is trivially rejected,
  all its children can be rejected with no further
  testing
• If a node is trivially accepted, all its children
  can be accepted with no further testing

38

• INTERMISSION

39
Cells and Portals

• Divide the scene into cells which can only see
  each other through portals
• Cells are stored in a k-D tree
• Once tree is set, cell portals (the transparent
  portions of shared boundaries) are identified and
  stored with each cell
• Also need to store where the portal leads

40

• Basically constructing an adjacency graph over
  the cells
• Two vertices are adjacent (share an edge) if and
  only if there is a portal connecting them

41
Example world
42

• Cell-to-cell visibility is determined by treating
  each cell as a light source
• Trace light outwards to find visible objects
• It overestimates, but not excessively

43

• Cell-to-cell visibility is stored for each cell.
  This is the set of cells visible to a generalized
  observer looking in all directions
• This set contains those cells with an
  unobstructed sightline from the originating cell

44

• Cells that are not neighbors must have sightlines
  that traverse a portal sequence
• Possible to find sightlines in O(n lg n)

45
Stab trees

• But how is this visibility computation possible?
• Use stab trees for each cell
• Each node of the stab tree corresponds to a cell
  visible from that cell
• Each edge of the stab tree corresponds to a
  portal stabbed as part of a portal sequence
• Use depth-first search on the adjacency graph

46
Cell-to-cell visibility stab tree
47

• Cells farther from the source may be marked as
  visible, but are generally only partially visible
• In general, only a fraction of most cells in the
  stab tree is visible to the source

48

• Each portal encountered during the graph
  traversal imposes constraints to the set of
  sightlines stabbing the sequence
• You end up with a bowtie-shaped bundle of lines
  that stabs every portal in the sequence

49

• This is not necessary for neighbor cells
• They are automatically marked as fully visible
• See next chart

50
Final result
51
Cell-to-object visibility

• This can then be used to determine object
  visibility in each cell
• Previously removed objects are put back into the
  scene based on the compacted representation of
  the stab tree

52
(No Transcript)
53
The payoff

• We have the cell-to-object set and we have the
  cells visible from the current eye position
• Intersect them together and you get an object set
  that is typically only slightly larger than the
  true visibility

54
References

• Visibility Computations in Polyhedral
  Environments
• http//sunsite.berkeley.edu/Dienst/UI/2.0/Describe
  /ncstrl.ucb/CSD-92-680?abstractTeller
• David Luebke, Assistant Professor of Computer
  Science
• http//www.cs.virginia.edu/luebke/

55

• Questions?