Maths & Technologies for GamesSpatial Partitioning 1

CO3303 Week 8-9

Contents

1. Introduction / Rationale2. Uses for Spatial Partitioning3. Potentially Visible Sets (PVS)4. Portal Systems

Introduction

• Spatial Partitioning is any scheme that divides the game world into smaller spaces

• We have previously considered the game world as a single huge area

• 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 many commercial games

Problems with Large Games

• A complex game world can contain millions of instances• The 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

Simple Culling Methods

• Can cull entity instances against the viewing frustum– The volume of space visible from camera– The shape is a trapezium

• Check each instance against each of the six planes defining the frustum– Reject any instance that lies entirely on

the outside of any one plane

• Or more simply: just reject those behind the camera near clip plane

• Use bounding volumes and simple maths– Boxes, AABB or spheres

• This approach sufficient for simple cases• Large game - still processing millions of

instances per-frame

Rationale for Spatial Partitioning

• Culling instances one-by-one is not the best approach for very complex environments– Too many instances to even consider in one frame

• Need to reformulate the problem:– Not “For each instance: Is this instance visible? Render, update…”– But “Select the visible instances. For each one…”

• Don’t process non-visible instances at all– Easier said than done…

• What if we consider partitions (chunks) of space?– With everything inside– Identify instead which partitions are (in)visible– Allowing use to accept / reject large groups of instances at once

Simple Example

• Most space partitioning schemes use some form of graph to subdivide the world– Each node represents a space– Shape of the spaces vary by scheme– The edges represent how the spaces

are related / connected

• This example shows a very basic partition / graph demonstrating:– How areas in the scene are connected– How a group of instances can be

rejected by one check

Level Division

• Space partitions are not just for visibility checks

• The can help in a variety of non-rendering situations

• Partitioning a game into levels should be familiar:– Or these could be sections of a

single level

• Traversal from section to section might imply:– Loading / releasing resources– New PP effects, lighting etc.– Changing music etc.

Game Logic

• Space partitions can also 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

Visibility / Audibility

• We will mainly consider partitions for determining visibility

• Could also use them to help calculate audibility:

• Many other uses for space partitions– Be imaginative

• May use multiple partitions schemes simultaneously for different purposes– Visibility, physics, logic, etc.

Potentially Visible Sets (PVS)

• Regardless of partitioning scheme, each node in a space partition has a potentially visible set (PVS):– The nodes that can, in some way, be

seen from that node– Independent of camera position within

the node

• The PVS is can be pre-calculated and stored with each node– Indicates which other nodes to render

when in that node– All other nodes rejected without

calculation

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 just the nodes visible from one camera position– But the nodes visible from any camera position

• Possible approaches:– Brute force: consider many different camera positions – slow,

possible errors– Manually create PVS: only possible for simpler graphs – error prone

(see this in lab)– Mathematical / geometric approaches – complex and often have

limitations

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 visible from only a tiny portion of the current node– It must be considered visible in the entire of the current node

• So whilst efficient to execute, PVS systems are not ideally effective in node rejection

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, regardless of scheme used– E.g. manually created graphs, portal systems or any of the other

partitioning schemes described later

• Used as a quick way to reduce number of nodes under consideration– Before using more complex techniques– Satisfies the paradigm from earlier – reject nodes (and hence many

entity instances) without any run-time calculation

Portal Systems

• A portal system is a method that concentrates on the graph edges– The connections between spaces– The nodes (spaces) in the partition

can be arbitrarily shaped

• Spaces in such a system are connected through portals– A portal is typically a natural opening

such as a door or window– In general a convex planar polygon

• Portals allow us to reject other nodes based on the camera view– A natural adjunct for a PVS system

Basic Portal Usage

• First identify which node the camera is in– Render that node’s instances– Some instances are in multiple

nodes, e.g. a door-frame– An issue in other schemes too

• Then identify whether each of the node’s portals are visible in the viewport– Use 2D work / frustum culling

• Now we know the nodes connected through the visible portals are also visible– Repeat process on those nodes

Refinements

• When visible portal is found store its viewport dimensions– A 2D rectangle

• Clip portals in the connected node against this smaller area– Only check for further portals

visible through the clipped area– Rejects obscured nodes– All relatively simple 2D processing

• Must watch out for multiple portals leading to same node– Don’t want to render nodes twice– Combine into a single area or store

“isRendered” state for each node

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 move or change size– Portals can be “opened” and “closed” by simply enabling or

disabling them

• Can make physically impossible portals, joining unexpected locations (e.g. the game “Portal”)– Each portal has two 2 sides that don’t need to be in the same place– Alter camera position when rendering through a portal– Change entity position when passing through a portal

Portal Drawbacks

• Given arbitrarily shaped nodes, it can be tricky to know which node a particular 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 are 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 or created from specific

assets (doors) or tools (level editor)