Maths & Technologies for Games Spatial Partitioning 1 CO3303 Week 8-9
Jan 17, 2018
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)