Maths & Technologies for Games Spatial Partitioning 1 CO3303 Week 8-9

Contents 1.Introduction / Rationale 2.Uses for Spatial Partitioning 3.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)