Emerging Technologies for Games Spatial Partitioning 1

1
Emerging Technologies for GamesSpatial
Partitioning 1

• CO3303
• Week 9-10

2
Contents

• Introduction / Rationale
• Uses for Spatial Partitioning
• Potentially Visible Sets (PVS)
• Portal Systems
• Rabin p456 onwards

3
Introduction

• Spatial Partioning is any scheme that divides the
  game world into smaller spaces
• We have previously considered the game world as a
  single space
• The game world has had a single global list of
  entity instances
• All instances rendered / processed every frame
• OK for small scale projects
• Not efficient enough for most commercial games

4
Problems with Large Games

• A game world can contain millions of instances
• Majority are likely to be far from the player
• Probably not visible as well
• Consider rendering all instances
• Viewport clipping removes off-screen instances
• Z buffer removes those hidden behind other things
• But all instances must still be processed
• Would like to cull these instances instead
• Identify that they are not visible quickly
• Remove them from processing earlier

5
Simple Culling Methods

• Can cull instances against the viewing frustum
• The cone visible from camera
• Or simpler, against the plane of the viewport
• Just reject those behind us
• Use bounding volumes and simple maths
• Boxes, AABB or spheres
• Sufficient for simple cases
• Large game - still processing millions of
  instances per-frame

6
Rationale for Spatial Partitioning

• Looking at instances one-by-one is not a
  reasonable approach
• Need to reformulate the problem
• Not For each instance Is this instance
  visible?
• But Which instances are visible? For each one
• Dont process non-visible instances at all
• What if we consider partitions (chunks) of space?
• With everything inside
• We can identify which partitions are (in)visible
• And accept / reject large groups of instances

7
Simple Example

• All space partitioning schemes use some form of
  graph to represent the world
• Each node is a space
• The edges represent how the spaces are related /
  connected
• This example shows a very basic partition / graph
• It demonstrates how an entire node of instances
  can be rejected at once

8
Level Division

• Space partitions can help in a variety of
  non-rendering situations
• Partitioning a game into levels should be
  familiar
• These could also be sections of a single level
• Traversal from section to section might imply
• Loading new resources, changing music etc.

9
Game Logic

• Space partitions can help with game logic needs

• Race track split into sectors
• Only current / neighbouring sectors used for
  opponent AI physics ( rendering)
• Simpler logic elsewhere
• Could apply to any game
• But here sectors also simplify lap processing
• Distance covered
• Wrong way detection
• Telemetrics gathering, etc

10
Visibility / Audibility

• We will generally consider partitions for
  determining visibility
• Could also use them to help calculate audibility
• Many other uses for space partitions too
• Many games use multiple partitions for different
  purposes

11
Potentially Visible Sets (PVS)

• Each node in a space partition has a potentially
  visible set
• The nodes that can, in some way, be seen from
  that node
• Independent of camera position
• The PVS is stored with each node and indicates
  which other nodes to render when in that node
• All other nodes rejected without calculation

12
Generating PVS

• A PVS scheme is conceptually simple
• Trivial run-time implementation
• However, generating the PVS for each node is
  non-trivial
• A PVS is not the nodes visible from one camera
  position
• But the nodes visible from any camera position
• Possible approaches
• Brute force, consider many camera positions
  slow, possible errors
• Manual, only possible for simpler graphs error
  prone
• Mathematical / geometric approaches complex and
  often have limitations

13
PVS Limitations

• A PVS does not consider dynamic geometry
• E.g. if a level contains a door that opens, then
  the door must be considered open for PVS
• Losing some possibilities for node rejection
• Possible to extend implementation to cover such
  cases
• Potentially visible sets must be conservative
• Consider a node that visible from only a tiny
  portion of the current node
• It is considered visible in the entire of the
  current node
• So whilst efficient to execute, they are not
  ideally effective in node rejection

14
PVS Use

• A PVS system is not a space partitioning scheme
  as such
• Rather a scheme for storing additional data in an
  existing graph
• Potentially visible sets can be added to any
  space partition graph
• E.g. a manually created graph
• Or any of the other partitioning schemes
  described subsequently
• Often used as a quick way to initially reject
  nodes
• Before using more complex techniques

15
Portal Systems

• A portal system allows space to be divided into
  arbitrarily shaped spaces (nodes)
• Spaces are connected through portals (edges)
• A portal is typically a natural opening between
  spaces, e.g. a door or window
• In general a convex planar polygon
• A node contains instances
• Some instances are in multiple nodes, e.g. a door
  / door-frame

16
Basic Portal Usage

• Need to know which node the camera is in
• Render that nodes instances
• Identify whether each of the nodes portals are
  visible in the viewport
• Could use frustum culling
• The nodes connected through the visible portals
  are also visible
• Repeat the process on these nodes, etc.

17
Refinements

• When visible portal is found store the viewport
  area it occupies
• Check portals in the connected node against this
  smaller area
• Improves culling
• This can be simplified by using bounding boxes
• Must also watch for multiple portals to same node
• Combine into a single area

18
Portal Benefits

• Portals are fairly cheap and simple to implement
• Extremely effective for indoor geometry where
  there are many natural portals
• Portals can handle dynamic geometry
• Portals can change shape
• Portals can be opened and closed by simply
  enabling or disabling them
• Can make physically impossible portals, joining
  unexpected locations see the game Portal
• Portal have 2 sides that match in size, but not
  in space
• Alter camera position when rendering through a
  portal
• Change entity position when passing through

19
Portal Drawbacks

• Tricky to know which node an arbitrary point is
  in
• In particular, we need to know which node the
  camera is in to start the algorithm
• Can keep track of camera as it moves between
  nodes
• What if the camera travels through a wall or
  teleports?
• Portals of little use for open areas
• No obvious portals everything tends to be
  visible
• Not at all easy to automatically generate portals
  from arbitrary geometry
• So portals are generally created manually (by
  artists)